Greg Freemyer wrote:

Sascha Peilicke wrote:

...

On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>

...

FYI: The driving force behind me packaging most of these is that

plaso

...

is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)

I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.

Hmm..

Maybe I should move it. A little background.

Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.

One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.

I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.

So the architecture is:

CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection

I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.

With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?

Thanks Greg

I forgot to say the one package I know of that they are struggling to replace is perl-image-exiftool. Exiftool can pull timestamp related metadata from a wide variety of docs/files (including images of course). They have tried the hachoir python library, but it isn't performing fast enough for their needs so they dropped it for now. In the current alpha release of plaso, they are simply not handling a lot of these files. If anyone knows a high-performance library to do what exiftool does, I will pass it along to the devs to evaluate. It only needs to read metadata, not write it like exiftool can do. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/25/2013 01:41 PM, Greg Freemyer wrote:

Sascha Peilicke wrote:

...

On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>

...

FYI: The driving force behind me packaging most of these is that

plaso

...

is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)

I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.

Hmm..

Maybe I should move it. A little background.

Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.

One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.

I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.

So the architecture is:

CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection

I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.

With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?

So if it's nowadays a mostly-Python or Python-only story, then d:l:p maybe an appropriate place. Otherwise we could at least link it to d:l:p similarly to python-qt4 and python-kde4 from KDE:Qt and KDE:Distro:Factory (AFAIR). If you want to have it über-awesome, have the base package named "plaso" and require a sub-package called python-plaso which contains everything under %{python_sitelib}. But if you don't expect anybody to ever import the Python modules, you can just go the easy route and name it plaso. d:l:p has several examples. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/25/2013 04:42 PM, Greg Freemyer wrote:

On Thu, Apr 25, 2013 at 8:49 AM, Sascha Peilicke wrote:

...

On 04/25/2013 01:41 PM, Greg Freemyer wrote:

...

Sascha Peilicke wrote:

...

On 04/24/2013 11:48 PM, Greg Freemyer wrote:

<snip>

...

...

FYI: The driving force behind me packaging most of these is that

plaso

...

is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)

I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.

Hmm..

Maybe I should move it. A little background.

Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.

One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.

I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.

So the architecture is:

CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection

I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.

With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?

So if it's nowadays a mostly-Python or Python-only story, then d:l:p maybe an appropriate place. Otherwise we could at least link it to d:l:p similarly to python-qt4 and python-kde4 from KDE:Qt and KDE:Distro:Factory (AFAIR).

If you want to have it über-awesome, have the base package named "plaso" and require a sub-package called python-plaso which contains everything under %{python_sitelib}. But if you don't expect anybody to ever import the Python modules, you can just go the easy route and name it plaso. d:l:p has several examples.

The SR is revoked for now. I will resubmit when I figure out what I want to do.

Hehe, take your time ;-) And thanks for the detailed explanation btw. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org