Hide Forgot
Spec URL: http://oirase.annexia.org/reviews/evtx/EvtxParser.spec SRPM URL: http://oirase.annexia.org/reviews/evtx/EvtxParser-1.0.7-1.fc15.src.rpm Description: Windows Event Log parsing tools For an example of using these tools see: https://rwmj.wordpress.com/2011/04/17/decoding-the-windows-event-log-using-guestfish/
Note that it's not possible to do a scratch build in Koji because this package requires perl-Data-Hexify (bug 705798).
rpmlint output is: EvtxParser.src: W: spelling-error %description -l en_US evtx -> Evert EvtxParser.src: W: spelling-error %description -l en_US evtxdump -> Dumpster EvtxParser.noarch: W: spelling-error %description -l en_US evtx -> Evert EvtxParser.noarch: W: spelling-error %description -l en_US evtxdump -> Dumpster EvtxParser.noarch: E: non-standard-executable-perm /usr/bin/evtxinfo.pl 0555L EvtxParser.noarch: E: non-standard-executable-perm /usr/bin/evtxdump.pl 0555L EvtxParser.noarch: E: non-standard-executable-perm /usr/bin/evtxtemplates.pl 0555L 2 packages and 0 specfiles checked; 3 errors, 4 warnings. I don't understand what "non-standard-executable-perm" is complaining about. It seems perfectly reasonable to use 0555 to me.
I sent the new Makefile.PL and the patch upstream.
Tried to build this in Mock and saw the following error: Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.vvj1p5 + umask 022 + cd /builddir/build/BUILD + cd evtxtools-1.0.7 + LANG=C + export LANG + unset DISPLAY + perl Makefile.PL INSTALLDIRS=vendor Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.vvj1p5 (%build) Bad exit status from /var/tmp/rpm-tmp.vvj1p5 (%build) Child returncode was: 1
Strange. perl(ExtUtils::MakeMaker) is a build requirement, so mock ought to install it. Is it expected that the Perl path should contain /usr/local?
Ping? Any progress here? Or we can close this review?
No, let's close this. If anyone's interested they can reopen it and take over the package.
Let's restart this URL with a brand new package: - - - - - Spec URL: http://oirase.annexia.org/reviews/evtx/perl-Parse-Evtx.spec SRPM URL: http://oirase.annexia.org/reviews/evtx/perl-Parse-Evtx-1.1.1-1.src.rpm Description: Windows Event Log parsing library and tools - - - - - rpmlint is completely clean. A koji scratch build is available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7045293
(In reply to Richard W.M. Jones from comment #8) > Let's restart this URL with a brand new package: s/URL/review/
Okay. I'll have a look at this one.
Licensing is correct. MANDATORY: The following BRs must be added. Making the full set of dependent libraries explicit in the build requirements will help protect this module from unexpected breakages when the default set of libraries available in the fedora build environment changes (from actions in the perl-core or by the fedora build team) BR: perl(base) - lib/Parse/Evtx/BXmlNode/NameString.pm at line 2 BR: perl(Carp) - lib/Parse/Evtx/VariantType.pm at line 62 BR: perl(Digest::MD5) - scripts/evtxtemplates.pl at line 51 BR: perl(Encode) - lib/Parse/Evtx/BXmlNode/NameString.pm at line 5 BR: perl(Encode::Unicode) - lib/Parse/Evtx/BXmlNode/NameString.pm at line 6 BR: perl(Exporter) - lib/Parse/Evtx/Const.pm at line 8 BR: perl(Fcntl) - lib/Parse/Evtx.pm at line 12 BR: perl(Getopt::Long) - scripts/evtxtemplates.pl at line 52 BR: perl(IO::File) >= 1.14 - scripts/evtxtemplates.pl at line 50 BR: perl(Math::BigInt) - lib/Parse/Evtx.pm at line 11 BR: perl(strict) - scripts/evtxtemplates.pl at line 44 BR: perl(version) - lib/Parse/Evtx.pm at line 15 RunTime Requirement for perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) The following files need to be added to the dos2unix call lib/Parse/Evtx.pm lib/Parse/Evtx/VariantType.pm Interestingly enough, this was missed by rpmlint. COMMENTS This is a really old (and i'm not sure if it's still supported) package. Is it worth urging the author to at least contribute the module to CPAN? That way, if http://computer.forensikblog.de/ is taken off line, you've got somewhere to work with the source package? I usually add a Group of "Development/Libraries", but i understand this is optional for Fedora. Similarly i usually add the optional dist support in the Release tag? However, I'm happy to approve the package once the BR and RunTime requirements have been fixed and the dos2unix updates have been applied.
I take back the comment about unix2dos. Unfortunately, for unknown reasons, unix2dos also fails to fix the problem. You can add the following two lines to fix the carriage returns at the end of line for these two files sed -i 's/\r//' lib/Parse/Evtx.pm sed -i 's/\r//' lib/Parse/Evtx/VariantType.pm
(In reply to David Dick from comment #12) > I take back the comment about unix2dos. Unfortunately, for unknown reasons, > unix2dos also fails to fix the problem. I guess you meant to use dos2unix? (In reply to David Dick from comment #11) > This is a really old (and i'm not sure if it's still supported) package. Is > it worth urging the author to at least contribute the module to CPAN? That > way, if http://computer.forensikblog.de/ is taken off line, you've got > somewhere to work with the source package? Interestingly there are two other evtx parsers available, one in Python and the other in C++: http://www.williballenthin.com/evtx/ https://code.google.com/p/libevtx/ The C++ one is pure evil. The Python one looks fairly sensible, and has some recent updates. I hit a very strange parsing bug when using this (Perl) parser, which prevents 'virt-log' from working. Still investigating ...
(In reply to Richard W.M. Jones from comment #13) > (In reply to David Dick from comment #12) > > I take back the comment about unix2dos. Unfortunately, for unknown reasons, > > unix2dos also fails to fix the problem. > > I guess you meant to use dos2unix? heh.. yeah, fair enough. dos2unix works fine. :)
I've taken a closer look at the newer python evtx library, and it seems to be more maintained. Therefore I have opened a new review for that: https://bugzilla.redhat.com/show_bug.cgi?id=1109717 http://oirase.annexia.org/reviews/python-evtx/ and I will close this one.