You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(40) |
Sep
(70) |
Oct
(45) |
Nov
(41) |
Dec
(65) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(46) |
Feb
(38) |
Mar
(30) |
Apr
(4) |
May
(24) |
Jun
(76) |
Jul
(104) |
Aug
(89) |
Sep
(39) |
Oct
(8) |
Nov
(9) |
Dec
(14) |
| 2003 |
Jan
(34) |
Feb
(21) |
Mar
(4) |
Apr
(2) |
May
(3) |
Jun
(17) |
Jul
(8) |
Aug
(1) |
Sep
(1) |
Oct
(11) |
Nov
(20) |
Dec
(8) |
| 2004 |
Jan
(22) |
Feb
(71) |
Mar
(17) |
Apr
(9) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Rohit P. <roh...@ya...> - 2006-09-04 15:26:06
|
Hi I am Rohit from India. I have taken ur systrace tool. As in compilation notes, i cd to tool's dir and type ./configure. It gives me an error as bad intrepeter::no directory. why this is happening?? my linux has distrubution kernel 2.4 of PCQ LINUX 2004 cds. --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
|
From: Muli Ben-Y. <mu...@mu...> - 2005-03-31 15:23:46
|
On Wed, Mar 30, 2005 at 04:22:59PM -0500, Craig Soules wrote: > Hello all, >=20 > I'm curious about the status of syscall tracker under linux 2.6. I have= =20 > been using a similar home-spun module to track syscalls in 2.4 for quite= =20 > some time now for use in my phd work. I'm looking to expand my tracing= =20 > to more users, however, many of the machines around here use 2.6, and so= =20 > I need a new solution. Has anyone on this list had any luck with doing= =20 > syscall interception in 2.6? Are there any plans to add syscall tracing= =20 > to the core kernel any time soon? No, becase its already been done :-) Check out the new audit framework's CONFIG_AUDITSYSCALL option. I haven't looked into it in any depth, but it seems to provide system call auditing. If all you need is "passive" surveilance, it should do the trick. If you want to take actions based on audit results, it could probably be extended. Also, since I haven't used it yet, I'll be interested in hearing your experiences with it. Cheers, Muli --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Craig S. <so...@ec...> - 2005-03-30 21:25:51
|
Hello all, I'm curious about the status of syscall tracker under linux 2.6. I have been using a similar home-spun module to track syscalls in 2.4 for quite some time now for use in my phd work. I'm looking to expand my tracing to more users, however, many of the machines around here use 2.6, and so I need a new solution. Has anyone on this list had any luck with doing syscall interception in 2.6? Are there any plans to add syscall tracing to the core kernel any time soon? Thanks for any pointers/help that you can provide. Craig Soules so...@cm... |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-06-20 07:35:32
|
On Sat, Jun 19, 2004 at 10:08:15AM +0300, Orna Agmon wrote: > > I am new to the area, and am looking for a software package > > the solve a debugging issue that I am not sure is feasible. > > In short, I would like to be able to intercept a system call > > and determine which command/funcion call in what C source > > file within the running application exercised that system > > call.=20 This can be done if you have debugging information on the executable. See for example how oprofile goes from EIP to instruction/function call.=20 > How about hijacking the system call using syscalltrack, and then > attaching gdb to it? That will work, if you don't mind doing it manually.=20 > Though I think this should require interfering with the code excuted > before (or after) the system call - I don't think there is a ready > mechanism for that, is there? Actually, there is - you can suspend the process (via action=3DSUSPEND in the syscalltrack rules file) and then attach to it with a debugger. Theoretically, it should work :-)=20 Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Orna A. <lad...@gr...> - 2004-06-19 07:08:29
|
On Fri, 18 Jun 2004, Marcio O. Buss wrote: > Date: Fri, 18 Jun 2004 12:03:21 -0400 (EDT) > From: Marcio O. Buss <ma...@cs...> > To: sys...@li... > Subject: [sct-hackers] Syscalltrack and debugging issues > > > Hi all, > > I am new to the area, and am looking for a software package > the solve a debugging issue that I am not sure is feasible. > In short, I would like to be able to intercept a system call > and determine which command/funcion call in what C source > file within the running application exercised that system > call. More precisely, for debugging purposes I would like > to be able to point out which line of source code was > responsible for a given type of system call. I imagine > compiling the source code using a "-g" like option and > then figuring this all out. > > Any help would be appreciated, > Thanks, > -Marcio. > How about hijacking the system call using syscalltrack, and then attaching gdb to it? Though I think this should require interfering with the code excuted before (or after) the system call - I don't think there is a ready mechanism for that, is there? Orna. |
|
From: Marcio O. B. <ma...@cs...> - 2004-06-18 16:03:28
|
Hi all, I am new to the area, and am looking for a software package the solve a debugging issue that I am not sure is feasible. In short, I would like to be able to intercept a system call and determine which command/funcion call in what C source file within the running application exercised that system call. More precisely, for debugging purposes I would like to be able to point out which line of source code was responsible for a given type of system call. I imagine compiling the source code using a "-g" like option and then figuring this all out. Any help would be appreciated, Thanks, -Marcio. |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-06-16 16:49:03
|
The paper mentioned below is temporarily available from http://www.mulix.org/misc/sudarshan.pdf=20 Cheers,=20 Muli=20 ----- Forwarded message from Sudarshan Srinivasan <sms...@ui...> ----- Date: Wed, 16 Jun 2004 11:22:00 -0500 =46rom: Sudarshan Srinivasan <sms...@ui...> X-Mailer: Microsoft Outlook, Build 10.0.2627 To: mu...@mu... Subject: Acknowledgement Hi, I'm a grad student at UIUC. I used syscalltrack for one of the projects that I'm working on- an extension to the Linux 2.4 kernel that allows processes to be rolled back to a previous execution state and re-executed deterministically (for cyclic debugging). I've attached a copy of the paper based on that project, which has been accepted for publication in the USENIX technical conference proceedings.=20 I found syscalltrack easy to extend and very useful. I wanted to thank you for making it available as open-source. I'll be releasing the code for Flashback soon. You can download it from http://carmen.cs.uiuc.edu. I'd appreciate comments and feedback. Thanks! Best wishes, Sudarshan ----- End forwarded message ----- --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: kapoor c. <kap...@ya...> - 2004-05-10 14:25:05
|
plz unsubscribe me from mailing list --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-05-09 08:28:28
|
[CC'd to sct-hackers]=20 On Sat, May 08, 2004 at 10:47:26PM +0200, GCS wrote: > Hi, >=20 > Do you still develop syscalltrack?=20 Not at the moment.=20 > What about kernel 2.6 support? We do have 2.6 support, but in a non-optimal way.=20 > If you do 2.6 support, I may pick up it for Debian. It's in CVS... we're talking about a release now, but it's likely to be the last release for quite some time, unless someone interested in maintaining it comes along.=20 Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-05-09 08:18:44
|
On Tue, May 04, 2004 at 12:24:34PM +0200, Axel Dittrich wrote: > Reading the mail archives, I found some mails discussing fullpath/fdpath= =20 > changes. But the patch is missing through the web interface. Amir, do you want to commit it?=20 > Will there be a new "official" version to get all the changes from CVS ? There should be... Amir, do you want to do it?=20 > How about the last patches for fullpath/fdpath support? > When get they included in the CVS tree or a official version? That's up to Amir.=20 Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Axel D. <axe...@ag...> - 2004-05-04 10:25:17
|
I'm not a member of this list, but would read it through the web interface. I have tried the last official version 0.82 with success. Reading the mail archives, I found some mails discussing fullpath/fdpath changes. But the patch is missing through the web interface. As I want to monitor file access on a running system. I looked in the new CVS files, like ChangLog and some dirs like doc/, logger/, sct_parselib/, sct_rules/ but didn't found any thing about fullpath/fdpath. So here comes my question: Will there be a new "official" version to get all the changes from CVS ? (I am behind a firewall and have no chance to run CVS directly, maybe I have to try it from home :-) How about the last patches for fullpath/fdpath support? When get they included in the CVS tree or a official version? Thanks for your help, Axel Dittrich |
|
From: Benno L. <ben...@id...> - 2004-05-03 07:14:31
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-04-17 13:23:02
|
On Thu, Apr 15, 2004 at 09:41:57AM +0300, Baruch Even wrote: > Hi, >=20 > I've just looked a bit at the code of sctrace (consider this a mini code > audit), and had a few things that I thought might be worth fixing. >=20 > Issues handled: > - Handling EINTR error code around blocking code (read and waitpid). > - Closing file handles that are only used to synchronize the parent and > son processes. > - Remove rules from SCT in various error situations. >=20 > Patch is attached. Applied, thank you! Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Baruch E. <ba...@ev...> - 2004-04-15 06:42:43
|
Hi, I've just looked a bit at the code of sctrace (consider this a mini code audit), and had a few things that I thought might be worth fixing. Issues handled: - Handling EINTR error code around blocking code (read and waitpid). - Closing file handles that are only used to synchronize the parent and son processes. - Remove rules from SCT in various error situations. Patch is attached. Baruch |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-04-15 06:38:01
|
On Thu, Apr 15, 2004 at 09:26:19AM +0300, Baruch Even wrote: > Yes, a --no-kernel option should be fine. If you can send me a patch I'd > have it in the Debian package until you release a version with this > option. I'll steal something from oprofile as soon as possible, commit and send it to you.=20 > > Thanks for doing this! >=20 > No problem, though my offer that you do it and I'll sponsor the package > still stands. I appreciate this; however, I won't have time for it in the near future.=20 Cheers,=20 Muli --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Baruch E. <ba...@ev...> - 2004-04-15 06:27:01
|
* Muli Ben-Yehuda <mu...@mu...> [040415 09:21]: > On Thu, Apr 15, 2004 at 12:04:53AM +0300, Baruch Even wrote: > > In version 0.72, I had the sct package generate two "binary" packages, > > one was a true binary for the utilities, the other was a source package > > for the module itself which every user should build for himself. > > > > I'd like to keep this setup for 0.82 too since I won't need to rebuild > > the module when a new kernel is released or when a security update is > > done. > > > > Instead of me working to figure how to circumvent the new ./configure > > scheme, maybe you could give me a hint, how do I go about compiling the > > utilities by themselves and the module later on. > > 'make userspace' should do it. Let me see... > - compilation works fine (CVS HEAD) > - configuration requires proper kernel sources. Will a --no-kernel > configure option be enough? Yes, a --no-kernel option should be fine. If you can send me a patch I'd have it in the Debian package until you release a version with this option. > > Is it possible at all? I hope the utilities don't need some kernel > > version dependent struct that will stop working on me for different > > versions. > > Let's just say, in theory they aren't, in practice, I've always built > them together so such dependency may have crept in. If that's the > case, we'll fix it. We'll be checking that... > Thanks for doing this! No problem, though my offer that you do it and I'll sponsor the package still stands. Baruch |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-04-15 06:21:12
|
On Thu, Apr 15, 2004 at 12:04:53AM +0300, Baruch Even wrote: > Hello, >=20 > I've woken up from the dead, and started to clean up my Debian packages, > SCT is the last in line, and since there are no other takers to handle > it, I thought I'll give it the update it needed. >=20 > In version 0.72, I had the sct package generate two "binary" packages, > one was a true binary for the utilities, the other was a source package > for the module itself which every user should build for himself. >=20 > I'd like to keep this setup for 0.82 too since I won't need to rebuild > the module when a new kernel is released or when a security update is > done. >=20 > Instead of me working to figure how to circumvent the new ./configure > scheme, maybe you could give me a hint, how do I go about compiling the > utilities by themselves and the module later on. 'make userspace' should do it. Let me see...=20 - compilation works fine (CVS HEAD) - configuration requires proper kernel sources. Will a --no-kernel configure option be enough?=20 > Is it possible at all? I hope the utilities don't need some kernel > version dependent struct that will stop working on me for different > versions. Let's just say, in theory they aren't, in practice, I've always built them together so such dependency may have crept in. If that's the case, we'll fix it.=20 Thanks for doing this! Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-04-15 06:11:15
|
The Light-weight auditing framewrk patch has been applied to the kernel, and will show up in 2.6.6. Getting syscalltrack to work with it is probably the way to go, even though it doesn't support the entire syscalltrack functionality.=20 ----- Forwarded message from Linux Kernel Mailing List <linux-kernel@vger.k= ernel.org> ----- Date: Mon, 12 Apr 2004 20:29:12 +0000 =46rom: Linux Kernel Mailing List <lin...@vg...> To: bk-...@vg... Subject: [PATCH] Light-weight Auditing Framework ChangeSet 1.2012, 2004/04/12 13:29:12-07:00, ak...@os... [PATCH] Light-weight Auditing Framework =09 From: Rik Faith <fa...@re...> =09 This patch provides a low-overhead system-call auditing framework for Linux that is usable by LSM components (e.g., SELinux). This is an update of the patch discussed in this thread: =09 http://marc.theaimsgroup.com/?t=3D107815888100001&r=3D1&w=3D2 =09 In brief, it provides for netlink-based logging of audit records that have been generated in other parts of the kernel (e.g., SELinux) as well as the ability to audit system calls, either independently (using simple filtering) or as a compliment to the audit record that another part of the kernel generated. =09 The main goals were to provide system call auditing with 1) as low overhead as possible, and 2) without duplicating functionality that is already provided by SELinux (and/or other security infrastructures). This framework will work "stand-alone", but is not designed to provide, e.g., CAPP functionality without another security component in place. =09 This updated patch includes changes from feedback I have received, including the ability to compile without CONFIG_NET (and better use of tabs, so use -w if you diff against the older patch). =09 Please see http://people.redhat.com/faith/audit/ for an early example user-space client (auditd-0.4.tar.gz) and instructions on how to try it. =09 My future intentions at the kernel level include improving filtering (e.g., syscall personality/exit codes) and syscall support for more architectures. First, though, I'm going to work on documentation, a (real) audit daemon, and patches for other user-space tools so that people can play with the framework and understand how it can be used with and without SELinux. =09 =09 Update: =09 Light-weight Auditing Framework receive filter fixes From: Rik Faith <fa...@re...> =09 Since audit_receive_filter() is only called with audit_netlink_sem held, it cannot race with either audit_del_rule() or audit_add_rule(), so the list_for_each_entry_rcu()s may be replaced by list_for_each_entry()s, and the rcu_read_{un,}lock()s removed. A fix for this is part of the attached patch. =09 Other features of the attached patch are: =09 1) generalized the ability to test for inequality =09 2) added syscall exit status reporting and testing =09 3) added ability to report and test first 4 syscall arguments (this adds a large amount of flexibility for little cost; not implemented or tested on ppc64) =09 4) added ability to report and test personality =09 User-space demo program enhanced for new fields and inequality testing: http://people.redhat.com/faith/audit/auditd-0.5.tar.gz # This patch includes the following deltas: # ChangeSet 1.2011 -> 1.2012=20 # arch/ppc64/kernel/entry.S 1.35 -> 1.36 =20 # kernel/fork.c 1.164 -> 1.165 =20 # include/linux/sched.h 1.191 -> 1.192 =20 # include/asm-ppc64/thread_info.h 1.10 -> 1.11 =20 # include/asm-i386/thread_info.h 1.17 -> 1.18 =20 # security/selinux/include/avc.h 1.5 -> 1.6 =20 # kernel/Makefile 1.38 -> 1.39 =20 # include/linux/fs.h 1.306 -> 1.307 =20 # arch/i386/kernel/entry.S 1.73 -> 1.74 =20 # arch/i386/kernel/ptrace.c 1.20 -> 1.21 =20 # arch/x86_64/kernel/ptrace.c 1.13 -> 1.14 =20 # fs/namei.c 1.93 -> 1.94 =20 # arch/x86_64/kernel/entry.S 1.20 -> 1.21 =20 # arch/x86_64/ia32/ia32entry.S 1.30 -> 1.31 =20 # include/asm-x86_64/thread_info.h 1.15 -> 1.16 =20 # security/selinux/avc.c 1.8 -> 1.9 =20 # init/Kconfig 1.35 -> 1.36 =20 # arch/ppc64/kernel/ptrace.c 1.8 -> 1.9 =20 # include/linux/netlink.h 1.14 -> 1.15 =20 # security/selinux/ss/services.c 1.8 -> 1.9 =20 # (new) -> 1.1 include/linux/audit.h # (new) -> 1.1 kernel/auditsc.c # (new) -> 1.1 kernel/audit.c=20 # arch/i386/kernel/entry.S | 6=20 arch/i386/kernel/ptrace.c | 10=20 arch/ppc64/kernel/entry.S | 15=20 arch/ppc64/kernel/ptrace.c | 29 + arch/x86_64/ia32/ia32entry.S | 18=20 arch/x86_64/kernel/entry.S | 21=20 arch/x86_64/kernel/ptrace.c | 30 + fs/namei.c | 15=20 include/asm-i386/thread_info.h | 6=20 include/asm-ppc64/thread_info.h | 3=20 include/asm-x86_64/thread_info.h | 5=20 include/linux/audit.h | 211 ++++++++ include/linux/fs.h | 14=20 include/linux/netlink.h | 1=20 include/linux/sched.h | 3=20 init/Kconfig | 20=20 kernel/Makefile | 2=20 kernel/audit.c | 825 ++++++++++++++++++++++++++++++++++ kernel/auditsc.c | 922 ++++++++++++++++++++++++++++++++++= +++++ kernel/fork.c | 10=20 security/selinux/avc.c | 168 +++---- security/selinux/include/avc.h | 7=20 security/selinux/ss/services.c | 2=20 23 files changed, 2199 insertions(+), 144 deletions(-) --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Muli Ben-Y. <mu...@mu...> - 2004-04-15 06:09:28
|
On Tue, Apr 13, 2004 at 04:17:21PM +0400, Sergey V. Burchu wrote: > Hello where! >=20 > I have some troubles using syscalltrack: > 1) using rules file (in attachment) I have "syscall 4 busy" message. > I think it becouse of atfer rule "write_a". Probably.=20 > 2) using the same rule as above I have trouble unloading modules: > sct_hijack: Device or resource busy > # lsmod=20 > Module Size Used by Not tainted > sct_hijack 139296 1 That's a feature, not a bug :-)=20 If the ssycall is busy, the hijack module cannot be safely removed.=20 > That all. You can wait until the syscall becomes unbusy (the specific invocation that was in it at the time of the unload has returned) and then try to remove the module again.=20 Cheers,=20 Muli=20 --=20 Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ |
|
From: Baruch E. <ba...@ev...> - 2004-04-14 21:06:18
|
Hello, I've woken up from the dead, and started to clean up my Debian packages, SCT is the last in line, and since there are no other takers to handle it, I thought I'll give it the update it needed. In version 0.72, I had the sct package generate two "binary" packages, one was a true binary for the utilities, the other was a source package for the module itself which every user should build for himself. I'd like to keep this setup for 0.82 too since I won't need to rebuild the module when a new kernel is released or when a security update is done. Instead of me working to figure how to circumvent the new ./configure scheme, maybe you could give me a hint, how do I go about compiling the utilities by themselves and the module later on. Is it possible at all? I hope the utilities don't need some kernel version dependent struct that will stop working on me for different versions. Baruch |
|
From: Sergey V. B. <sa...@bu...> - 2004-04-13 12:18:00
|
Hello where! I have some troubles using syscalltrack: 1) using rules file (in attachment) I have "syscall 4 busy" message. I think it becouse of atfer rule "write_a". 2) using the same rule as above I have trouble unloading modules: sct_hijack: Device or resource busy # lsmod Module Size Used by Not tainted sct_hijack 139296 1 .. Though before it it was shown that modules are not used, only sct_hijack was used by rules. Such situation is only after sct_config upload .. ;cat /dev/sct_log; sct_config delete; If I only do sct_load;sct_unload everything is ok. That all. -- Burchu Sergey |
|
From: <yy...@it...> - 2004-03-25 10:16:06
|
Hello Nice job and did me a lot of favor. Although sys_call_table isn't exported on Redhat 8/9, I found this may be a solution without patch/(re)compile kernel. http://www.stacken.kth.se/lists/arla-drinkers/2003-05/msg00005.html The method in "Arla" project is to find some special syscall addresses in "init_mm" structure, such as sys_read and sys_write. (init_mm, sys_read, and sys_write are all exported) Then if found, the sys_call_table can be determined. I have tested that in syscalltrack project and it seems works. |
|
From: Danny R. F. <fa...@te...> - 2004-03-23 16:27:28
|
I run a mailing list for software testers called swtest-discuss (http://lists.topica.com/lists/swtest-discuss/). There are a few people there (including me) who are interested in talking about how people do testing for open source projects. I haven't yet found a community of open source testers that cuts across multiple tools/applications. (Sorry if you've seen this announcement before - I'm casting a wide net.) Maybe you've helped to test syscalltrack itself, or maybe you've used it to test an open source program. If you're interested in sharing your experiences in testing open source software, please consider joining swtest-discuss, at least long enough to see if there's any interest in having an on-going forum on this topic. If you do subscribe, please either send me a private email or introduce yourself to the list so we know you're there. So far we have representatives from the Open Source Development Lab (OSDL), the FitNesse project, JUnit, the Perl community, and the Free Software Foundation. I think the OSDL would be especially interested in hearing from the syscalltrack folks if you haven't been in touch with them before. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/ |
|
From: Danny R. F. <fa...@te...> - 2004-03-23 16:01:16
|
I run a mailing list for software testers called swtest-discuss (http://lists.topica.com/lists/swtest-discuss/). There are a few people there (including me) who are interested in talking about how people do testing for open source projects. I haven't yet found a community of open source testers that cuts across multiple tools/applications. (Sorry if you've seen this announcement before - I'm casting a wide net.) Maybe you've helped to test syscalltrack itself, or maybe you've used it to test an open source program. If you're interested in sharing your experiences in testing open source software, please consider joining swtest-discuss, at least long enough to see if there's any interest in having an on-going forum on this topic. If you do subscribe, please either send me a private email or introduce yourself to the list so we know you're there. So far we have representatives from the Open Source Development Lab (OSDL), the FitNesse project, JUnit, and the Perl community. I think the OSDL would be especially interested in hearing from the syscalltrack folks if you haven't been in touch with them before. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/ |
|
From: Baruch E. <ba...@ev...> - 2004-03-16 10:08:09
|
* Muli Ben-Yehuda <mu...@mu...> [040316 10:11]: > Hi Baruch, > > Are you still maintaining the sct package in debian? If yes, it's > sorely in need of an upgrade. If not, maybe someone else wants to do > it? I'm long behind updating it, I'm sorely aware of that. If there is someone else who can maintain it I'll be more than pleased to pass the torch. I believe I filed an RFA for it in the WNPP. If you or someone else who is not a Debian Developer wants to maintain it and I'll sponsor the upload, it's an option too. I do that with rubber which I wanted in the archive but didn't have the time to maintain myself. This way the upstream author (this means YOU!) maintains the Debian package too and I only do some final checks, sign and upload. It will also mean that whomever will be the maintainer will be given the proper credit for that and will be tasked with handling the bug reports in the BTS. I'll be providing the guidance and help needed. I hope to find some time to do the tasks I need, but syscalltrack is not high in my priorities. Baruch |