You can subscribe to this list here.
2009 |
Jan
(15) |
Feb
(56) |
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(16) |
May
(7) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(2) |
Mar
(21) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
From: Aaron T. <syn...@gm...> - 2009-02-17 00:42:24
|
Quick sit rep. 3.4.1 should be going out the door soon. I need to do a quick test of tcpbridge under OSX and that should be it. For 4.0, I've been trying to build cmake files for compiling the libopts tearoff. I'm pretty far along, but there are some things which cmake doesn't seem to handle out of the box- like checking for typedefs being defined outside of stddef.h, sys/types.h and stdint.h. This makes checking for wint_t on OS X (which is defined in runetype.h) a lot harder then it should. Once I have a libopts building from cmake and I can throw away autotools I'll start looking at creating the tcpreplay/prep API's. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |
From: Abdelrazak Y. <you...@gm...> - 2009-02-02 09:52:02
|
Aaron Turner wrote: > Just merged in all the cmake code from win32port to trunk. Should > build under OS X and RHEL4. There is still some cleanup to do of > course, but it should be stable enough for everyone to work off trunk > now. I'm still planning on some build environment tweaks- hopefully I > can fully remove autotools in the near future. > That's very good news. > Right now, in order to build, you'll need autotools (recent versions > recommended) in order to build libopts for the cli tools. Running > 'make' after cmake should auto-run configure and build libopts. Once > things stabilize a little more, I'll try to get some of the people who > build packages for various OS's do their testing so I can get that out > of the way. > > Abdel- If you need me to work on the tcpreplay/tcpprep API's sooner > then later, let me know and I'll adjust the priorities accordingly. > Nothing hot on my side, I just started with tcpedit controls and that's enough for me for the time being. I worked a bit (2h) on the GUI this week-end but nothing showable yet. > Anyways, beer is in the cooler, need to start up the BBQ and finish > getting ready for the big game. > Have fun and enjoy :-) Abdel. |
From: Aaron T. <syn...@gm...> - 2009-02-01 22:23:15
|
Just merged in all the cmake code from win32port to trunk. Should build under OS X and RHEL4. There is still some cleanup to do of course, but it should be stable enough for everyone to work off trunk now. I'm still planning on some build environment tweaks- hopefully I can fully remove autotools in the near future. Right now, in order to build, you'll need autotools (recent versions recommended) in order to build libopts for the cli tools. Running 'make' after cmake should auto-run configure and build libopts. Once things stabilize a little more, I'll try to get some of the people who build packages for various OS's do their testing so I can get that out of the way. Abdel- If you need me to work on the tcpreplay/tcpprep API's sooner then later, let me know and I'll adjust the priorities accordingly. Anyways, beer is in the cooler, need to start up the BBQ and finish getting ready for the big game. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-30 18:01:06
|
I have all the code building under OS X w/ cmake. All unit tests are passing! Working on getting it to build under RHEL 4.x. Once that works, I'll merge to trunk. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-29 08:58:52
|
On Wed, Jan 28, 2009 at 11:42 PM, Abdelrazak Younes <you...@gm...> wrote: > Hi Aaron, > > Aaron Turner wrote: >> Anyways, I've decided that maintaining cmake & auto* in parallel is >> probably more work then it's worth. I know it's going to be painful >> in the short term, but I'd rather deal with this once then deal with >> maintaining two systems over the long term. Basically my short term >> goal is to be able to build everything on two platforms (RH Linux & OS >> X) via cmake. Once that happens, I'll merge into trunk and try to >> find some people to test it on other platforms. Abdel, I assume I can >> count on you to help some with the Windowsification cmake stuff. :) >> > > Yes, I'll do my best. I think you made a wise decision :-) Actually, it's looking that way... I'm pretty close to getting everything to build on OS X. :) >> After that, I'll work on librarization of tcpprep & tcpreplay so they >> can build under Windows for the GUI. I don't have any plans right now >> to do tcpbridge, but that would be easy to do. >> > > So can I assume tcpedit is already completely librarified? Is it merged > into trunk yet? Yep. Perhaps you might want me to add you to the svn commits list? That or you can subscribe to tickets in Trac that you're interested in. >> My goal is to get all of this done in the next month or so- basically >> before the motorcycle trackday/racing season starts up here in >> California. Once that starts, my free time for tcpreplay will take a >> hit as I'm spending more weekends at the track and weekends/evenings >> working on the bike. It's a bit aggressive time wise, but it's good >> to have goals > I am afraid my free time is very scarce these day sbecause of a new big > project at work. I'll try to resume my work on the Gui this week-end and > commit an initial skeleton. Cool. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |
From: Abdelrazak Y. <you...@gm...> - 2009-01-29 07:42:58
|
Hi Aaron, Aaron Turner wrote: > Anyways, I've decided that maintaining cmake & auto* in parallel is > probably more work then it's worth. I know it's going to be painful > in the short term, but I'd rather deal with this once then deal with > maintaining two systems over the long term. Basically my short term > goal is to be able to build everything on two platforms (RH Linux & OS > X) via cmake. Once that happens, I'll merge into trunk and try to > find some people to test it on other platforms. Abdel, I assume I can > count on you to help some with the Windowsification cmake stuff. :) > Yes, I'll do my best. I think you made a wise decision :-) > After that, I'll work on librarization of tcpprep & tcpreplay so they > can build under Windows for the GUI. I don't have any plans right now > to do tcpbridge, but that would be easy to do. > So can I assume tcpedit is already completely librarified? Is it merged into trunk yet? > My goal is to get all of this done in the next month or so- basically > before the motorcycle trackday/racing season starts up here in > California. Once that starts, my free time for tcpreplay will take a > hit as I'm spending more weekends at the track and weekends/evenings > working on the bike. It's a bit aggressive time wise, but it's good > to have goals I am afraid my free time is very scarce these day sbecause of a new big project at work. I'll try to resume my work on the Gui this week-end and commit an initial skeleton. Cheers, Abdel. |
From: Aaron T. <syn...@gm...> - 2009-01-28 19:45:02
|
Hey Abdel, etc. Figured I'd give a quick sit rep on where I stand. Based on bug reports and issues I've found on my own, I'm spec'ing out the 3.4.1 release. I'll be posting to the users list soon to give everyone a chance to comment on the tickets & open any new issues. My goal is to limit 3.4.1 to a small list so it doesn't interfere too much with 4.0. Current list of tickets is here: http://tcpreplay.synfin.net/trac/query?group=status&milestone=3.4.1&order=priority For 4.0, I'm still working on the cmake scripts. I've basically given up on trying to write CMakeLists.txt file(s) for the libopts tear off, so I'm going to have a configure stub to build that. Shouldn't be a problem since libopts won't be used under Windows. Anyways, I've decided that maintaining cmake & auto* in parallel is probably more work then it's worth. I know it's going to be painful in the short term, but I'd rather deal with this once then deal with maintaining two systems over the long term. Basically my short term goal is to be able to build everything on two platforms (RH Linux & OS X) via cmake. Once that happens, I'll merge into trunk and try to find some people to test it on other platforms. Abdel, I assume I can count on you to help some with the Windowsification cmake stuff. :) After that, I'll work on librarization of tcpprep & tcpreplay so they can build under Windows for the GUI. I don't have any plans right now to do tcpbridge, but that would be easy to do. My goal is to get all of this done in the next month or so- basically before the motorcycle trackday/racing season starts up here in California. Once that starts, my free time for tcpreplay will take a hit as I'm spending more weekends at the track and weekends/evenings working on the bike. It's a bit aggressive time wise, but it's good to have goals. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin |
From: Abdelrazak Y. <you...@gm...> - 2009-01-20 09:03:34
|
Aaron Turner wrote: > Quick update... figured out the issue with cmake... as you might > imagine the error was between chair & keyboard. > That's good new because I couldn't find the reason with my 5 minutes looking at it :-) Abdel. |
From: Abdelrazak Y. <you...@gm...> - 2009-01-20 08:57:34
|
Aaron Turner wrote: >>> All things being equal, if I can dump auto* I probably >>> will... Would mean building cmake files for libopts which won't be a >>> ton of fun though... or is there a way to maybe call configure from >>> cmake and get the Makefiles to play nice? >>> >> I guess it's possible and I think I've read something about that but I >> cannot find it in google. I am afraid this is out of my current knowledge... >> > > Worst case, if I do switch to cmake, you'll have to go into libopts, > run ./configure && make then go back to the main directory and run > cmake && make. > OK. >>> Wouldn't need libopts for >>> Windows so no need to worry about VC++. >>> >>> >> Well, unless I am missing something command-line parsing will be needed >> for VC++ too. Unless you have specific requirement for Autopts, maybe >> it'd be better to switch to a cross platform library then? Or even do it >> ourself? >> > > Why would we need any CLI parsing for the GUI? Or are you suggesting > there be a CLI version under Windows too? Yes, either a CLI version or an executable that would work in GUI or CLI mode. For example in LyX, the '-e' option for export is a CLI tool, the GUI is not started nor loaded. > Honestly, the chances of me > switching or writing my own is slim to nil right now. I'd rather work > on improving the GUI to reach feature parity then re-writing option > parsing code. > Fair enough, just forget about it forget it. Abdel. |
From: Aaron T. <syn...@gm...> - 2009-01-20 05:39:50
|
Quick update... figured out the issue with cmake... as you might imagine the error was between chair & keyboard. Still can't even compile my first .c file, but I'm getting close! -Aaron On Mon, Jan 19, 2009 at 11:04 AM, Aaron Turner <syn...@gm...> wrote: > On Mon, Jan 19, 2009 at 5:52 AM, Abdelrazak Younes > <you...@gm...> wrote: >> Aaron Turner wrote: >>> Lots of progress over the weekend with cmake in the win32port feature >>> branch. >> You are going too fast for me :-) >> Not that I am complaining... But I feel bad about having not really >> started yet. > > Hah! My evil plan to use guilt to motivate you is working! :) > Seriously, though I know how it is- my goal right now is really to > remove any roadblocks so that when you do start working I won't be in > the way. That and I better use the free time I have now, because I > know in a few months I won't have nearly as much. > >>> All things being equal, if I can dump auto* I probably >>> will... Would mean building cmake files for libopts which won't be a >>> ton of fun though... or is there a way to maybe call configure from >>> cmake and get the Makefiles to play nice? >> >> I guess it's possible and I think I've read something about that but I >> cannot find it in google. I am afraid this is out of my current knowledge... > > Worst case, if I do switch to cmake, you'll have to go into libopts, > run ./configure && make then go back to the main directory and run > cmake && make. > >>> Wouldn't need libopts for >>> Windows so no need to worry about VC++. >>> >> >> Well, unless I am missing something command-line parsing will be needed >> for VC++ too. Unless you have specific requirement for Autopts, maybe >> it'd be better to switch to a cross platform library then? Or even do it >> ourself? > > Why would we need any CLI parsing for the GUI? Or are you suggesting > there be a CLI version under Windows too? Honestly, the chances of me > switching or writing my own is slim to nil right now. I'd rather work > on improving the GUI to reach feature parity then re-writing option > parsing code. > > >>> Anyways, other then the fun of porting all my tests over, the one >>> thing I can't figure out is how to properly do variable substitution >>> in CONFIGURE_FILE() >>> >>> Until then, I'm kinda hosed as I can't generate src/defines.h >>> properly... >> >> Maybe you can have a look at the CMake files used in LyX: >> >> svn://svn.lyx.org/lyx/lyx-devel/trunk/development/cmake > > thanks, I'll take a look > >>> Abdel, if you have time to look at the win32port and see >>> what might be going on with @LPCAPINC@ that would be great... looks >>> like >>> >>> SET(LPCAPINC ${PCAP_INCLUDE_DIRS}/pcap.h PARENT_SCOPE) >>> >>> in FindPCAP.cmake doesn't actually do what I expect. >>> >> >> I'll try to have a look today. > > awesome! > > -- > Aaron Turner > http://synfin.net/ > http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows > They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety. -- Benjamin Franklin > |
From: Aaron T. <syn...@gm...> - 2009-01-19 19:04:33
|
On Mon, Jan 19, 2009 at 5:52 AM, Abdelrazak Younes <you...@gm...> wrote: > Aaron Turner wrote: >> Lots of progress over the weekend with cmake in the win32port feature >> branch. > You are going too fast for me :-) > Not that I am complaining... But I feel bad about having not really > started yet. Hah! My evil plan to use guilt to motivate you is working! :) Seriously, though I know how it is- my goal right now is really to remove any roadblocks so that when you do start working I won't be in the way. That and I better use the free time I have now, because I know in a few months I won't have nearly as much. >> All things being equal, if I can dump auto* I probably >> will... Would mean building cmake files for libopts which won't be a >> ton of fun though... or is there a way to maybe call configure from >> cmake and get the Makefiles to play nice? > > I guess it's possible and I think I've read something about that but I > cannot find it in google. I am afraid this is out of my current knowledge... Worst case, if I do switch to cmake, you'll have to go into libopts, run ./configure && make then go back to the main directory and run cmake && make. >> Wouldn't need libopts for >> Windows so no need to worry about VC++. >> > > Well, unless I am missing something command-line parsing will be needed > for VC++ too. Unless you have specific requirement for Autopts, maybe > it'd be better to switch to a cross platform library then? Or even do it > ourself? Why would we need any CLI parsing for the GUI? Or are you suggesting there be a CLI version under Windows too? Honestly, the chances of me switching or writing my own is slim to nil right now. I'd rather work on improving the GUI to reach feature parity then re-writing option parsing code. >> Anyways, other then the fun of porting all my tests over, the one >> thing I can't figure out is how to properly do variable substitution >> in CONFIGURE_FILE() >> >> Until then, I'm kinda hosed as I can't generate src/defines.h >> properly... > > Maybe you can have a look at the CMake files used in LyX: > > svn://svn.lyx.org/lyx/lyx-devel/trunk/development/cmake thanks, I'll take a look >> Abdel, if you have time to look at the win32port and see >> what might be going on with @LPCAPINC@ that would be great... looks >> like >> >> SET(LPCAPINC ${PCAP_INCLUDE_DIRS}/pcap.h PARENT_SCOPE) >> >> in FindPCAP.cmake doesn't actually do what I expect. >> > > I'll try to have a look today. awesome! -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Abdelrazak Y. <you...@gm...> - 2009-01-19 13:53:12
|
Aaron Turner wrote: > Lots of progress over the weekend with cmake in the win32port feature > branch. You are going too fast for me :-) Not that I am complaining... But I feel bad about having not really started yet. > All things being equal, if I can dump auto* I probably > will... Would mean building cmake files for libopts which won't be a > ton of fun though... or is there a way to maybe call configure from > cmake and get the Makefiles to play nice? I guess it's possible and I think I've read something about that but I cannot find it in google. I am afraid this is out of my current knowledge... > Wouldn't need libopts for > Windows so no need to worry about VC++. > Well, unless I am missing something command-line parsing will be needed for VC++ too. Unless you have specific requirement for Autopts, maybe it'd be better to switch to a cross platform library then? Or even do it ourself? > Anyways, other then the fun of porting all my tests over, the one > thing I can't figure out is how to properly do variable substitution > in CONFIGURE_FILE() > > Until then, I'm kinda hosed as I can't generate src/defines.h > properly... Maybe you can have a look at the CMake files used in LyX: svn://svn.lyx.org/lyx/lyx-devel/trunk/development/cmake > Abdel, if you have time to look at the win32port and see > what might be going on with @LPCAPINC@ that would be great... looks > like > > SET(LPCAPINC ${PCAP_INCLUDE_DIRS}/pcap.h PARENT_SCOPE) > > in FindPCAP.cmake doesn't actually do what I expect. > I'll try to have a look today. Abdel. |
From: Aaron T. <syn...@gm...> - 2009-01-19 06:35:10
|
Lots of progress over the weekend with cmake in the win32port feature branch. All things being equal, if I can dump auto* I probably will... Would mean building cmake files for libopts which won't be a ton of fun though... or is there a way to maybe call configure from cmake and get the Makefiles to play nice? Wouldn't need libopts for Windows so no need to worry about VC++. Anyways, other then the fun of porting all my tests over, the one thing I can't figure out is how to properly do variable substitution in CONFIGURE_FILE() Until then, I'm kinda hosed as I can't generate src/defines.h properly... Abdel, if you have time to look at the win32port and see what might be going on with @LPCAPINC@ that would be great... looks like SET(LPCAPINC ${PCAP_INCLUDE_DIRS}/pcap.h PARENT_SCOPE) in FindPCAP.cmake doesn't actually do what I expect. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-18 22:45:51
|
Head colds suck, but it hasn't stopped me from cleaning up the API code. L3+ setters are now living in tcpedit_api.c rather then being dumped in tcpedit.c. There was also the minor issue that the API didn't give you a way to set the output (encoder) DLT plugin, so you couldn't convert DLT types- resolved via tcpedit_set_encoder_dltplugin_byid() and tcpedit_set_encoder_dltplugin_byname(). Doxygen on the website has been updated with the latest code (btw, you can just run 'make doxygen' and you'll get a local copy in docs/web/) I've also started updating the libtcpedit wiki page with information on the configuration API so you're not stuck trying to figure out how things work by reading the code. It's not complete, but should hopefully give you enough info to get started. If you'd like me to clarify anything let me know. http://tcpreplay.synfin.net/trac/wiki/libtcpedit -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-17 23:37:20
|
Just about ready to merge into trunk. Things are quite a bit simpler now- basically I split all the typedefs into *_types.h and functions into separate headers. All the public API functions are defined in *_api.h Basically it just means you need to add -Itcpedit to your CFLAGS and #include "tcpedit.h". Anyways, just need to fix a regression bug which showed up (unit tests are good) and then I'll merge over. I don't have any unit tests for the API right now... I suppose I could do something, but seems like a low priority right now. After merging, I guess I start figuring out this CMake thing. :) Also, all this work should make libtcpedit a lot easier to release as a standalone library in the future. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-17 23:19:28
|
http://tcpreplay.synfin.net/doxygen/html/ -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-17 23:17:20
|
-- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |
From: Aaron T. <syn...@gm...> - 2009-01-17 04:14:13
|
As I indicated, this list does not receive emails generated by Trac for tickets or for SVN commits. If anyone would like to receive emails for either (or both), please let me know. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin |