queue-developers Mailing List for GNU Queue (Page 11)
Brought to you by:
wkrebs
Menu
▾
▴
queue-developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(4) |
Jul
(4) |
Aug
(25) |
Sep
(9) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(15) |
Feb
(31) |
Mar
(26) |
Apr
(44) |
May
(39) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(9) |
Jun
(9) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lee B. <le...@se...> - 2000-08-05 02:38:09
|
On Fri, Aug 04, 2000 at 09:06:04PM -0400, W. G. Krebs wrote: > It would be nice to know what sort of functionality you are adding to GNU Queue. > This helps reduce duplication of effort if someone else is making similar > changes. OpenSource works best if developers contribute their modifications to > the general project. You can submit your modifications as patches to the Patch > archive on SourceForge (or just post them here if they are small.) Thanks for answering Monica's questions. She's trying to add support for tools that require software licenses (such as those managed by the flexlm license manager). We've talked about sending a description of her plans to you or the mailing list, but she hasn't had time to write anything yet. We'd like to make sure her modifications (or something similar) are acceptable to the queue community so that they will be included in future versions of the software. -- Lee Bradshaw le...@se... (preferred) Alantro Communications le...@al... |
|
From: W. G. K. <wer...@ya...> - 2000-08-05 01:21:03
|
Yes, you posted a similar question to queue-developers; I'll answer your more extensive email here. GNU Queue transmits a number of environmental factors to the server. These include things such as current working directory and the environment variables. These are stored in the Job Control File, the format of which is described in the recently published Internet Draft white paper, http://www.ietf.org/internet-drafts/draft-krebs-gnuqueue-protocol-00.txt (see previous message). This describes 1.20.1, 1.12.9 is a bit dated at this point. The code for all of this is in queue.c and later read by handle.c, which writes this information to the file (or to a socket, really). Just look at the code, it is fairly well commented. It would be nice to know what sort of functionality you are adding to GNU Queue. This helps reduce duplication of effort if someone else is making similar changes. OpenSource works best if developers contribute their modifications to the general project. You can submit your modifications as patches to the Patch archive on SourceForge (or just post them here if they are small.) ----- Forwarded message from Monica Lau <ml...@al...> ----- Date: Thu, 3 Aug 2000 10:55:34 -0700 (PDT) From: Monica Lau <ml...@al...> Reply-To: Monica Lau <ml...@al...> Subject: Queue Question To: wer...@ya... Hi Mr. Krebs, I am working on a project that involves adding more functionality to the Queue software. I have an important problem that I'm stuck on, and I can't move forward with this project until I figure this out. I know that you're very busy, but I really hope that you can help me with this problem. I am currently using Queue 1.12.9, but my question is quite general. In a nutshell, this is what I'm asking: if I want to run queue on host "grape" with the environment of host "apple," is this possible? So, if I enter "queue -- pwd" on grape, the result should be the pwd of apple, not the pwd of grape. Or if I enter "queue -- ls" on grape, the result should be the directory listing of apple, not grape. Is this possible? How do I pass apple's environment to grape? The reason why I'm asking is because I have a central server that accepts connections from clients. So, if a client enters "queue -- pwd," this information would get to the central server. This central server would then fork off a child process to run queue with the environment of the client. What I have tried doing is sending the client's "arge" array to the central server via a socket, and then the server does an exeve("queue", ..., arge). Unfortunately, this does not work. So, I'm not sure how else to pass the client's environment to the server. I mean, when I specify that queue run as batch mode on host "orange," the queue daemon somehow knows about orange's environment. How does the queue daemon know about orange's environment? If I can figure out how the queue daemon knows about the client's environment, then I can hopefully move forward with my project. Thank you for your help. I truly appreciate it. Sincerely, Monica ----- End forwarded message ----- |
|
From: W. G. K. <wer...@ya...> - 2000-08-05 01:12:49
|
An internet draft of the protocol used by GNU Queue is now available: http://www.ietf.org/internet-drafts/draft-krebs-gnuqueue-protocol-00.txt This describes the protocol used in 1.20.1 (except that 1.20.1 still uses TCP/IP, so it is an "experimental implementation" of the Open GNU Queue protocol.) Internet drafts are published (in an horrible ASCII format) for comments from the community. Quoting Eric Thayer <eh...@iC...>: > Since the documentation seems to be out of date WRT version 1.20.1, is > there anything wrong with my understanding here? > > On the every host's local filesystem there are (in the standard config): > > /usr/local/var/queue/{now,wait} > /usr/local/share/qhostsfile > > Every host in qhostsfile runs queued > > queued accepts work from queue(1) via a socket (NOT by noticing new cf > files in /usr/local/var/queue/...) > > queued on each machine maintains its own queue state in > /usr/local/var/queue/{now,...} > > ...eric > Yes, this is correct. However, the var/queue can still be shared, although it is not recommended. > > > _______________________________________________ > Queue-developers mailing list > Que...@li... > http://lists.sourceforge.net/mailman/listinfo/queue-developers > |
|
From: W. G. K. <wer...@ya...> - 2000-08-05 01:07:11
|
----- Forwarded message from no...@so... ----- Date: Wed, 2 Aug 2000 15:53:05 -0700 From: no...@so... Reply-To: no...@so... Subject: [queue - Open Discussion] RE: queued's deadlock 1.20.1 To: no...@so... Read and respond to this message at: http://sourceforge.net/forum/message.php?msg_idE330 By: wkrebs Around line 3021 in queued.c is there is an #undef TRANSMIT_DEBUG If you comment this line out, or remove it, QueueD will fork off another process whenever it wants to spool a job out to another machine. This should end the deadlock situation. However, one thing the call to wakeup() does is determine if there are any other hosts available in this batch queue to send the job to. If the answer is no, it stops trying for the moment --- 120 seconds or the next submission into the queue. The fork() loses this information, so I'm not sure how it will behave. (This can besolved with some sort IPC; open a pipe probably, but it will add a lot of code that doesn't do a whole lot except determine a return value.) Hopefully, it will fix the deadlock problem, though. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge and visit: http://sourceforge.net/forum/monitor.php?forum_id272 ----- End forwarded message ----- |
|
From: Monica L. <ml...@al...> - 2000-08-03 18:56:13
|
Hi, When the user specifies that a job run as batch mode, how does the user's environment get passed down to the queue daemon? Or, how does the queue daemon know about the user's environment? Thanks for the help! Monica |
|
From: Eric T. <eh...@iC...> - 2000-08-02 13:40:34
|
Since the documentation seems to be out of date WRT version 1.20.1, is
there anything wrong with my understanding here?
On the every host's local filesystem there are (in the standard config):
/usr/local/var/queue/{now,wait}
/usr/local/share/qhostsfile
Every host in qhostsfile runs queued
queued accepts work from queue(1) via a socket (NOT by noticing new cf
files in /usr/local/var/queue/...)
queued on each machine maintains its own queue state in
/usr/local/var/queue/{now,...}
...eric
|
|
From: W. G. K. <wer...@ya...> - 2000-07-30 20:28:53
|
The much anticipated release 1.20.1 is out on Sourceforge. This fixes -- job spooling problem in prelease is fixed; jobs will now propagate after sitting idle on a server if they can't be run. -- changes to bring Queue in compliance with forthcoming draft protocol. -- many other changes and fixes to 1.20 pre-release version; see ChangeLog for complete details. known problems: this version probably still has the /dev/tty chown bug (on Debian systems) when complied without NOROOT--- I need people to help me debug this better. I guess NOROOT is the more supported usage. :-) |
|
From: W. G. K. <wer...@ya...> - 2000-07-27 01:43:20
|
The pids of the jobs are stored in "pid" in the "struct job" structure. You can 'grep' the source code for where this structure is used. Hope this helps. Monica Lau wrote: > Hi, > > I am using Queue version 1.12.9. In the queued.c source code, it keeps > track of the pid of the forked off queue daemons. However, does it keep > track of the pid of the actual job that it is running? I am having > trouble finding this actual job pid in the code. For example, I > want to run "xclock." The parent queue daemon forks off a child queue > daemon, and this child queue daemon is in turn the parent of the xclock > process. I want to know the pid of this xclock process. Does anyone know > where this pid is kept in the code? > > Thanks, > Monica > > > _______________________________________________ > Queue-developers mailing list > Que...@li... > http://lists.sourceforge.net/mailman/listinfo/queue-developers |
|
From: Monica L. <ml...@al...> - 2000-07-14 19:49:21
|
Hi, I am using Queue version 1.12.9. In the queued.c source code, it keeps track of the pid of the forked off queue daemons. However, does it keep track of the pid of the actual job that it is running? I am having trouble finding this actual job pid in the code. For example, I want to run "xclock." The parent queue daemon forks off a child queue daemon, and this child queue daemon is in turn the parent of the xclock process. I want to know the pid of this xclock process. Does anyone know where this pid is kept in the code? Thanks, Monica |
|
From: Philippe W. <phi...@gu...> - 2000-07-12 19:43:04
|
I am now looking at queue (during my free time :) to see if this could not improve our development environment. The situation : We are doing Air Traffic Flow Management for complete Europe and We have a big application (1400000 lines of Ada code). We are currently in the process of changin of Ada compiler (in order to use the gnu Ada compiler instead of a proprietary compiler). I would like to see how I could use queue to improve the compilation speed of the system. I describe hereafter 2 possible options and some questions. Any feedback would be appreciated. Option 1: --------- The gnu ada compiler has an automatic make facility (gnatmake) that supports parallel compilation. Giving e.g. -j6 argument means : do 6 compilations in parallel. The compilation command can also be given as an argument to gnatmake (default = gcc). To make use of queue, I would give a big number of parallel compilation (e.g. 20) and specify that the command to use is a shell script that would call : queue .... gcc file_to_compile I do not understand if I have to use the immediate argument of queue (-i) or if I have to use the -q argument. I have not really understood what is the difference between the now spooldir, the queue spooldir and I also saw a wait spooldir. Option 2: --------- gnatmake has also an option : instead of starting compilation process, it can also only give the list of compilation command to do. This list could then be processed so as to be a serie of queue command. What kind of commands should it be ? Then, a question/suggestion : Sometimes, gcc process size becomes huge (>200Mb) when compiling some files containing generic instantiation (i.e. C++ "templates" but for Ada). Is there a way to control queue algorithm so that a job is started on a computer only if there is enough swap space available ? Thanks for any hint helping me to use gnu-queue + gnu-ada compiler together. -- Philippe WAROQUIERS Eurocontrol - Central Flow Management Unit phi...@cf... Rue de la fusee, 96 Tel: +32 2 729 97 35 Brussels Fax: +32 2 729 90 22 Belgium |
|
From: W. G. K. <wer...@ya...> - 2000-06-22 17:00:13
|
This depends on what version you are using. Versions below 1.20.0 (e.g., 1.12.8) store this information (command line information, &c) in a file that is available to the queue daemon at the remote host via NFS. These versions simply open a TCP/IP socket connection to tell the remote host to look for new files in its NFS directory. Versions 1.20.0 and higher (in pre-release) send this file directly to the remote host via TCP/IP (thus eliminating the need for NFS.) I hope this helps. If you make any changes to GNU Queue that might be of interest to other users, in the spirit of OpenSource software I hope you will submit the patches to either bug...@gn... or the patch facility on Sourceforge. Thanks. Monica Lau wrote: > Hi everyone! > > I am a student intern, working on a project that involves modifying a > little bit of the Queue software. First, however, I must understand the > source code in order to do so. I have been looking at the "queue.c" > source code for two days now, and I am having trouble understanding the > big picture. Can someone please give me a general overview of what > queue.c is doing? After it parses the command line options and finds the > load of all the hosts, then what does it do? I mainly want to understand > how queue communicates with the queue daemon at the remote host, how > information from what the user types on the command line gets transferred > over to the queue daemon. > > Thank you, > Monica > > _______________________________________________ > Queue-developers mailing list > Que...@li... > http://lists.sourceforge.net/mailman/listinfo/queue-developers |
|
From: Monica L. <ml...@al...> - 2000-06-22 16:28:38
|
Hi everyone! I am a student intern, working on a project that involves modifying a little bit of the Queue software. First, however, I must understand the source code in order to do so. I have been looking at the "queue.c" source code for two days now, and I am having trouble understanding the big picture. Can someone please give me a general overview of what queue.c is doing? After it parses the command line options and finds the load of all the hosts, then what does it do? I mainly want to understand how queue communicates with the queue daemon at the remote host, how information from what the user types on the command line gets transferred over to the queue daemon. Thank you, Monica |
|
From: Henry T. <cc...@uc...> - 2000-06-15 15:42:40
|
On Thu, 8 Jun 2000, W. G. Krebs wrote: > This was posted to one of the Queue message Forums on Sourceforge.... > > Perhaps users would like to share their thoughts in response, either > here or on Sourceforge? > > [ Part 2: "Included Message" ] > > Date: Thu, 8 Jun 2000 09:34:38 -0700 > From: no...@so... > To: no...@so... > Subject: [queue - Open Discussion] New Features > > Read and respond to this message at: > http://sourceforge.net/forum/message.php?msg_id=32247 > By: prensing > > I am currently using Condor as a batch system, but find Gnu Queue an > interesting alternative. However, there are clearly some things missing. > > The biggest thing is a set of user commands to monitor jobs. I started writing > a little script (in Python, since I want to experiment with that language), > but have not gotten very far. > > Does anyone have a set of scripts for monitoring, adding, deleting, etc.? What > do people think is needed? I was about to ask this question myself: I think this is a brilliant idea, and necessary if our site, for one, is to use queue as a batch system, as I would like to. I would like to contribute something along these lines myself, but I don't understand enough about how to get at queue's information about the jobs. Perhaps I'm missing something, but I haven't found any way (apart from standard unix tools such as ps) to find out what is going on once you've submitted some jobs. Off the top of my head, useful functions would be: List status of own jobs (user account) List status of all jobs (priviliged account) add own job to a queue (user account) delete own job from a queue (user account) delete any job from a queue (priviliged account) move any job up/down the queue (priviliged account) It would also be good if there was some priority measure which (for instance) discriminated in favour of jobs that have been waiting a long time, and against jobs from a user who already has a lot of jobs queued. It's unclear to me whether queue has this sort of facility. cheers ===================================================================== Henry Tillotson e-mail: h.t...@uc... User Support phone: 0171 380 7827 Information Systems fax: 0171 388 5406 University College London, Gower Street, London WC1 E 6BT, UK ===================================================================== |
|
From: W. G. K. <wer...@ya...> - 2000-06-08 17:10:21
|
This was posted to one of the Queue message Forums on Sourceforge.... Perhaps users would like to share their thoughts in response, either here or on Sourceforge? |
|
From: W. G. K. <wer...@ya...> - 2000-05-25 20:29:15
|
This is dying in the same place in both queue and queued. It is doing network setup, reading the /etc/netconfig file (which would be done by a library function, probably on a setup call to the DNS library functions.) My guess is that it is dying in ReadHosts in qlib.c . Try seting a breakpoint for ReadHosts in qlib.c and single stepping through the function. Hope this helps! > read(4, " #\n # T h e " N e t".., 8192) = 1064 > read(4, 0x0002F304, 8192) = 0 > llseek(4, 0, SEEK_CUR) = 1064 > llseek(4, 0, SEEK_SET) = 0 > read(4, " #\n # T h e " N e t".., 8192) = 1064 > read(4, 0x0002F304, 8192) = 0 > llseek(4, 0, SEEK_CUR) = 1064 > close(4) > Eugene Bradley wrote: > Hello! (sorry for the big email but I wanted to be as information- > specific as possible) > > Despite successful compiliation of GNU queue 1.19.2 on a Sun Ultra 1 > running Solaris 2.6 HW 5/98, attempting to run queue or queued as a > regular user and as root with any option other than --help or --version > causes the binary to segfault and dump core. I was wondering why > this was happening... [snip.] |
|
From: Eugene B. <ebr...@us...> - 2000-05-24 23:48:11
|
Hello! (sorry for the big email but I wanted to be as information-
specific as possible)
Despite successful compiliation of GNU queue 1.19.2 on a Sun Ultra 1
running Solaris 2.6 HW 5/98, attempting to run queue or queued as a
regular user and as root with any option other than --help or --version
causes the binary to segfault and dump core. I was wondering why
this was happening...
Note: no *.h, *.c, or Makefile-like files mentioned were modified other
than what the configure script performed.
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
Built on Wed Dec 29 18:27:36 PST 1999
3 ap226sun:/alt/home/ebradley > uname -a
SunOS ap226sun 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-1
4 ap226sun:/alt/home/ebradley > /usr/local/bin/make --version
GNU Make version 3.76.1, by Richard Stallman and Roland McGrath.
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Report bugs to <bug...@pr...>.
5 ap226sun:/alt/home/ebradley/queue-1.12.9 > /usr/local/bin/gcc
--version
2.8.1
6 ap226sun:/alt/home/ebradley/queue-1.12.9 > ./configure --enable-root
[...]
7 ap226sun:/alt/home/ebradley/queue-1.12.9 > /usr/local/bin/make
cd . && /alt/home/ebradley/queue-1.12.9/missing aclocal
WARNING: `aclocal' is missing on your system. You should only need it
if
you modified `acinclude.m4' or `configure.in'. You might want
to install the `Automake' and `Perl' packages. Grab them from
any GNU archive site.
cd . && /alt/home/ebradley/queue-1.12.9/missing automake --gnu Makefile
WARNING: `automake' is missing on your system. You should only need it
if
you modified `Makefile.am', `acinclude.m4' or `configure.in'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
cd . && /alt/home/ebradley/queue-1.12.9/missing autoconf
WARNING: `autoconf' is missing on your system. You should only need it
if
you modified `configure.in'. You might want to install the
`Autoconf' and `GNU m4' packages. Grab them from any GNU
archive site.
[...]
Host access control file is
"/usr/local/share/qhostsfile"
NFS-shared Queue spool directory is
"/usr/local/com/queue"
Local queued process id file prefix is
"/usr/local/var/queued.pid"
Error mail goes to
"root"
creating
./config.status
cd .
\
&& CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh
./config.status
creating
Makefile
cd . && /alt/home/ebradley/queue-1.12.9/missing
autoheader
WARNING: `autoheader' is missing on your system. You should only need
it if
you modified `acconfig.h' or `configure.in'. You might
want
to install the `Autoconf' and `GNU m4' packages. Grab
them
from any GNU archive
site.
cd .
\
&& CONFIG_FILES= CONFIG_HEADERS=config.h
\
/bin/sh
./config.status
creating
config.h
8 ap226sun:/alt/home/ebradley/queue-1.12.9 > make
20 ap226sun:/alt/home/ebradley/queue-1.12.9 > make
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c queue.c
queue.c: In function `send_signal':
queue.c:130: warning: passing arg 2 of `send' from incompatible pointer
type
queue.c: In function `main':
queue.c:792: warning: passing arg 2 of `accept' from incompatible
pointer type
queue.c:852: warning: passing arg 5 of `setsockopt' makes integer from
pointer t
queue.c:1041: warning: passing arg 4 of `setsockopt' from incompatible
pointer e
queue.c:1253: warning: passing arg 4 of `setsockopt' from incompatible
pointer e
queue.c:1259: warning: passing arg 4 of `setsockopt' from incompatible
pointer e
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c wakeup.c
wakeup.c: In function `con_daemon':
wakeup.c:79: warning: passing arg 2 of `connect' discards `const' from
pointer e
wakeup.c: In function `getrldavg':
wakeup.c:125: warning: passing arg 2 of `connect' discards `const' from
pointere
wakeup.c: In function `wakeup':
wakeup.c:174: warning: passing arg 4 of `qsort' from incompatible
pointer typegcc -g -O2 -o queue queue.o wakeup.o ident.o qlib.o
getloadavg.o setenv.o si
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
queued.c
queued.c: In function
`waitforchild':
queued.c:972: warning: passing arg 1 of `wait' from incompatible pointer
type
queued.c: In function
`check_query':
queued.c:3676: warning: passing arg 4 of `setsockopt' from incompatible
pointere
queued.c:3684: warning: passing arg 2 of `bind' from incompatible
pointer type
queued.c:3701: warning: passing arg 4 of `setsockopt' from incompatible
pointere
queued.c:3710: warning: passing arg 2 of `bind' from incompatible
pointer type
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
lex.c
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
handle.c
handle.c: In function
`bigsigh':
handle.c:210: warning: passing arg 2 of `send' from incompatible pointer
type
handle.c: In function
`handle':
handle.c:390: warning: passing arg 1 of `gethostbyaddr' from
incompatible pointe
handle.c:581: warning: passing arg 2 of `accept' from incompatible
pointer type
handle.c:722: warning: passing arg 1 of `open' makes pointer from
integer withot
a case
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
pty.c
gcc -g -O2 -o queued queued.o lex.o handle.o ident.o pty.o qlib.o
-ll getlo
Truss output of queue:
execve("/usr/local/bin/queue", 0xEFFFFC70, 0xEFFFFC8C) argc = 6
open("/dev/zero", O_RDONLY) = 3
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xEF7B0000
open("/usr/lib/libkvm.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF7A0000
mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF780000
munmap(0xEF784000, 57344) = 0
mmap(0xEF792000, 9900, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 8192) = 0xEF792000
close(4) = 0
open("/usr/lib/libelf.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF7A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF7A0000
mmap(0x00000000, 180224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF750000
munmap(0xEF76A000, 57344) = 0
mmap(0xEF778000, 10576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 98304) = 0xEF778000
close(4) = 0
open("/usr/lib/libxnet.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF7A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF7A0000
close(4) = 0
open("/usr/lib/libnsl.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF740000
mmap(0x00000000, 581632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF680000
munmap(0xEF6F0000, 57344) = 0
mmap(0xEF6FE000, 36828, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 450560) = 0xEF6FE000
mmap(0xEF708000, 19896, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF708000
close(4) = 0
open("/usr/lib/libsocket.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 106496, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF720000
munmap(0xEF728000, 57344) = 0
mmap(0xEF736000, 8185, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 24576) = 0xEF736000
mmap(0xEF738000, 388, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF738000
close(4) = 0
open("/usr/lib/librpcsvc.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF660000
munmap(0xEF666000, 57344) = 0
mmap(0xEF674000, 6452, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 16384) = 0xEF674000
close(4) = 0
open("/usr/lib/libc.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 704512, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF580000
munmap(0xEF614000, 57344) = 0
mmap(0xEF622000, 28432, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 598016) = 0xEF622000
mmap(0xEF62A000, 2592, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF62A000
close(4) = 0
open("/usr/lib/libdl.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
close(4) = 0
open("/usr/lib/libmp.so.2", O_RDONLY) = 4
fstat(4, 0xEFFFF814) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF650000
mmap(0x00000000, 81920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF560000
munmap(0xEF564000, 57344) = 0
mmap(0xEF572000, 3581, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 8192) = 0xEF572000
close(4) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xEF640000
open("/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF5F4) = 0
mmap(0xEF650000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF650000
mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF550000
close(4) = 0
close(3) = 0
munmap(0xEF650000, 8192) = 0
getuid() = 0 [0]
getuid() = 0 [0]
stat("/usr/local/share/qhostsfile", 0xEFFFD788) = 0
open("/usr/local/share/qhostsfile", O_RDONLY) = 3
fstat64(3, 0xEFFFD630) = 0
brk(0x0002C998) = 0
brk(0x00030998) = 0
ioctl(3, TCGETA, 0xEFFFD5BC) Err#25 ENOTTY
read(3, " a p 2 2 6 s u n\n", 8192) = 9
read(3, 0x0002C9A4, 8192) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, " a p 2 2 6 s u n\n", 8192) = 9
open("/etc/netconfig", O_RDONLY) = 4
fstat64(4, 0xEFFFD010) = 0
brk(0x00030998) = 0
brk(0x00032998) = 0
ioctl(4, TCGETA, 0xEFFFCF9C) Err#25 ENOTTY
read(4, " #\n # T h e " N e t".., 8192) = 1064
read(4, 0x0002F304, 8192) = 0
llseek(4, 0, SEEK_CUR) = 1064
llseek(4, 0, SEEK_SET) = 0
read(4, " #\n # T h e " N e t".., 8192) = 1064
read(4, 0x0002F304, 8192) = 0
llseek(4, 0, SEEK_CUR) = 1064
close(4) = 0
Incurred fault #6, FLTBOUNDS %pc = 0x00000000
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
*** process killed ***
Truss output for queued:
execve("./queued", 0xEFFFFC98, 0xEFFFFCA0) argc = 1
open("/dev/zero", O_RDONLY) = 3
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xEF7B0000
open("/usr/lib/libkvm.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF7A0000
mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF780000
munmap(0xEF784000, 57344) = 0
mmap(0xEF792000, 9900, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 8192) = 0xEF792000
close(4) = 0
open("/usr/lib/libelf.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF7A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF7A0000
mmap(0x00000000, 180224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF750000
munmap(0xEF76A000, 57344) = 0
mmap(0xEF778000, 10576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 98304) = 0xEF778000
close(4) = 0
open("/usr/lib/libxnet.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF7A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF7A0000
close(4) = 0
open("/usr/lib/libnsl.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF740000
mmap(0x00000000, 581632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF680000
munmap(0xEF6F0000, 57344) = 0
mmap(0xEF6FE000, 36828, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 450560) = 0xEF6FE000
mmap(0xEF708000, 19896, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF708000
close(4) = 0
open("/usr/lib/libsocket.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 106496, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF720000
munmap(0xEF728000, 57344) = 0
mmap(0xEF736000, 8185, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 24576) = 0xEF736000
mmap(0xEF738000, 388, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF738000
close(4) = 0
open("/usr/lib/librpcsvc.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF660000
munmap(0xEF666000, 57344) = 0
mmap(0xEF674000, 6452, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 16384) = 0xEF674000
close(4) = 0
open("/usr/lib/libc.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
mmap(0x00000000, 704512, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF580000
munmap(0xEF614000, 57344) = 0
mmap(0xEF622000, 28432, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 598016) = 0xEF622000
mmap(0xEF62A000, 2592, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xEF62A000
close(4) = 0
open("/usr/lib/libdl.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0xEF740000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF740000
close(4) = 0
open("/usr/lib/libmp.so.2", O_RDONLY) = 4
fstat(4, 0xEFFFF84C) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF650000
mmap(0x00000000, 81920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF560000
munmap(0xEF564000, 57344) = 0
mmap(0xEF572000, 3581, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 8192) = 0xEF572000
close(4) = 0
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xEF640000
open("/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1", O_RDONLY) = 4
fstat(4, 0xEFFFF62C) = 0
mmap(0xEF650000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0)
= 0xEF650000
mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xEF550000
close(4) = 0
close(3) = 0
munmap(0xEF650000, 8192) = 0
brk(0x000477A0) = 0
brk(0x000497A0) = 0
uname(0xEFFFF1C8) = 1
open("/etc/netconfig", O_RDONLY) = 3
fstat64(3, 0xEFFFEFB8) = 0
brk(0x000497A0) = 0
brk(0x0004B7A0) = 0
ioctl(3, TCGETA, 0xEFFFEF44) Err#25 ENOTTY
read(3, " #\n # T h e " N e t".., 8192) = 1064
read(3, 0x00047F04, 8192) = 0
llseek(3, 0, SEEK_CUR) = 1064
llseek(3, 0, SEEK_SET) = 0
read(3, " #\n # T h e " N e t".., 8192) = 1064
read(3, 0x00047F04, 8192) = 0
llseek(3, 0, SEEK_CUR) = 1064
close(3) = 0
Incurred fault #6, FLTBOUNDS %pc = 0x00000000
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
*** process killed ***
--
Eugene Bradley ebr...@us...
UNIX System Administrator voice: (650)506-2008
Application Dev. Services pager: (800)724-3624, #1682020
Oracle Corporation f a x: (650)506-7802
500 Oracle Parkway, Maildrop 3op2, Redwood Shores, CA 94065 |
|
From: Werner G. K. <wer...@ya...> - 2000-05-23 19:37:02
|
Apparantly RedHat and Suse aren't quite 100% compatible;
you need to add the followin lines from /usr/include/linux/resource.h^under
RedHat. If SuSe has /usr/include/linux/resource.h, it is somehow not being
included (perhaps because it is not referenced in Suse from an include file
referenced by RedHat.)
Hope this helps.
cc: queue-developers list.
--cut here--
struct rlimit {
long rlim_cur;
long rlim_max;
};
#define PRIO_MIN (-20)
#define PRIO_MAX 20
#define PRIO_PROCESS 0
#define PRIO_PGRP 1
#define PRIO_USER 2
--cut here --
Elya Guyer wrote:
> Hi!
> Thanks for the reply, firstly.
> As for the errors , I downloaded 1.12.9 , and I still get the same :
>
> gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c queue.c
> queue.c: In function `main':
> queue.c:481: storage size of `myrlimit' isn't known
> queue.c:752: `PRIO_PROCESS' undeclared (first use in this function)
> queue.c:752: (Each undeclared identifier is reported only once
> queue.c:752: for each function it appears in.)
> queue.c:756: sizeof applied to an incomplete type
> queue.c:852: warning: passing arg 5 of `setsockopt' makes integer from
> pointer without a cast
> make: *** [queue.o] Error 1
>
> I'm using Suse 6.3, and it is quite compatable with Radhat in my
> experience.
> Besides I indeed cann't find `myrlimit' type anywhere in the system.Any
> ideas?
> Elya
>
> "W. G. Krebs" wrote:
>
> > Ummm, 1.12 is not the latest version of Queue. The latest stable version
> > is 1.12.9, and the latest development version is 1.20.1pre4 .
> >
> > You should make sure you really have 1.12.9 and not something else.
> >
> > GNU Queue has been extensively tested under RedHat Linux distributions.
> > 5.2 through 6.2.
> >
> > What distribution of linux are you using?
> >
> > > Hi!
> > > I'm trying to build latest queue (1.12) on linux ( gcc version 2.95.1)
> > > and getting following
> > > errors:
> > > gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c queue.c
> > > queue.c: In function `main':
> > > queue.c:477: storage size of `myrlimit' isn't known
> > > queue.c:746: `PRIO_PROCESS' undeclared (first use in this function)
> > > queue.c:746: (Each undeclared identifier is reported only once
> > > queue.c:746: for each function it appears in.)
> > > queue.c:750: sizeof applied to an incomplete type
> > > queue.c:846: warning: passing arg 5 of `setsockopt' makes integer from
> > > pointer without a cast
> > > make: *** [queue.o] Error 1
> > >
> > > Seems some headers are missing , I guess
> > > Any ideas would be haghly appreciated
> > > Thanx in advance
> > >
> > > Elya Guyer
> > > Compugen SysAdmin
|
|
From: Werner K. <wer...@ya...> - 2000-05-23 01:00:20
|
The patch should fix the queued.c compile problem, but there is still the ./configure hang problem on HP-UX. I give instructions on how to properly fix the ./configure problem in the support information below by tweaking `configure.in' and running GNU 'autoconf' on HP-UX, (or on RedHat Linux where it is usually already installed --- output is platform independent.) Alternatively, you can just type Control-] to kill telnet in the ./configure; this will get around the problem as well (but may misdiagnose identd support.) "Werner G. Krebs" wrote: > The following patch should fix the HP-UX queued.c compile time problem. > > The patch is for 1.12.9. > > The patch can be retrieved at: > http://sourceforge.net/patch/?func=detailpatch&patch_id=100428&group_id=5605 > > _______________________________________________ > Queue-developers mailing list > Que...@li... > http://lists.sourceforge.net/mailman/listinfo/queue-developers > Support Request #101868, which you submitted on 05/18/00 14:21 > has been updated. You can respond by visiting: > http://sourceforge.net/support/?func=detailsupport&support_id=101868&group_id=5605 > > Category: None > Status: Open > Priority: 5 > Summary: Configure & Compile HPUX 10.20 > > By: mbrown > Date: 05/19/00 09:15 > > Message: > Logged In: YES > user_id=33778 > Browser: Mozilla/4.7 [en] (X11; I; HP-UX B.10.20 9000/785) > > I did the autoconf, and the configure seemed to go okay. > This time, configure said that I did not have a working > identd on port 113 (non-root can use netstat on my system). > After my original modification to the configure script, it > said I had a working identd on port 113. > > When I ran gmake, it gave an error since line 3860 of the > configure was missing an if statement: > then cat >> confdefs.h <<\EOF > > Replacing this with the corresponding line from the original > configure script, gmake got to the same point as originally. > > Mike > > ---------------------------------------------------------------------- > > By: wkrebs > Date: 05/19/00 06:51 > > Message: > Logged In: YES > user_id=32209 > Browser: Mozilla/4.51 [en] (X11; I; Linux 2.2.5-15smp i686) > > OK, the problem with telnet in ./configure is known on some > systems. If you look in the CVS repository, you'll see that > 1.12.7 used netstat instead of telnet to try to determine > this. However, netstat didn't work on some systems because > ordinary users lacked the privileges to run it. > > Find out if non-root users can run netstat under HP-UX. If > so, the patch is > to change the following TWO lines in configure.in: > > --Cut here > dnl AC_CACHE_CHECK(for working identd service on port 113, > queue_cv_service_identd, if netstat -nat | grep ':113.*:' > >/dev/null 2>&1 ; then queue_cv_service_identd=yup; else > queue_cv_service_identd=nope; fi) > > AC_CACHE_CHECK(for working identd service on port 113, > queue_cv_service_identd, if eval "echo | telnet localhost > 113 2>/dev/null | grep -i Connected >/dev/null 2>&1" ; then > queue_cv_service_identd=yup; else > queue_cv_service_identd=nope; fi) > if eval "test $queue_cv_service_identd = yup"; then > AC_DEFINE(HAVE_IDENTD) > fi > ---Cut here > TO: > ---Cut here > AC_CACHE_CHECK(for working identd service on port 113, > queue_cv_service_identd, if netstat -nat | grep ':113.*:' > >/dev/null 2>&1 ; then queue_cv_service_identd=yup; else > queue_cv_service_identd=nope; fi) > > dnl AC_CACHE_CHECK(for working identd service on port 113, > queue_cv_service_identd, if eval "echo | telnet localhost > 113 2>/dev/null | grep -i Connected >/dev/null 2>&1" ; then > queue_cv_service_identd=yup; else > queue_cv_service_identd=nope; fi) > if eval "test $queue_cv_service_identd = yup"; then > AC_DEFINE(HAVE_IDENTD) > fi > --- Cut here > > Of course, then you need to re-run GNU autoconf to > regenerate ./configure on your system. (autoconf is now > installed by default on many Redhat systems, and the output > is machine-independent; you can also get it from the FSF if > you don't have RedHat lying around. > > This should solve the first problem; once this is fixed, > we'll take it from there. > > |
|
From: Werner G. K. <wk...@bi...> - 2000-05-22 21:03:34
|
The following patch should fix the HP-UX queued.c compile time problem. The patch is for 1.12.9. The patch can be retrieved at: http://sourceforge.net/patch/?func=detailpatch&patch_id=100428&group_id=5605 |
|
From: Werner G. K. <wer...@ya...> - 2000-05-18 19:03:55
|
Hi, I released 1.12.9 via the release mechanism on Sourceforge yesterday, but I didn't immediately update the older queue-latest.tar.gz link on my Yale machine. This link is still referenced off the FSF Queue page, and some of you may have followed it. I've fixed the queue-latest link to point to 1.12.9. I've changed the homepage under my control to point people to Sourceforge for the latest releases. If in doubt as to what version you have, "queue --version" will tell you. Also, "grep -i version configure.in" on the distribution will tell you without having to compile anything. Sorry about the snafu. |
|
From: Werner G. K. <wer...@ya...> - 2000-05-17 23:49:52
|
After vowing never to put out another version of Queue with the old NFS mechanism, here is another one. This one replaces the OS-dependent load average code in queued.c with a call to getloadavg() from GNU Emacs, as suggested by Dan Nicolaescu <da...@ic...>. This should eliminate the problems Solaris and other users were having with this code. The new version is available for download from SourceForge.at http://sourceforge.net/project/?group_id=5605 . I've also updated queued.c to reflect this changed in the 'queue-development' branch of the CVS repository on SourceForge; check the project's SourceForge page for more details. Please let me know if anyone catches any last-minute problems before I start wrapping this up into a distribution on the GNU ftp mirrors. >From the Changelog: *May 17, 2000 Werner G. Krebs <wk...@gn...> 1.12.9 rolled out. As suggested by Dan Nicolaescu <da...@ic...>, removed OS-dependent load-average code in getloadf() in queued.c. Instead, changed queued.c to obtain load averages using getloadavg.c from GNU Emacs distribution, which now handles the OS-dependent work. This should fix the problem Solaris users were having with GNU Queue. Updated the documentation (README, Install, and pages in doc) to reflect GNU Queue's status as a member of SourceForge. Changed unofficial homepage to http://queue.sourceforge.net, and changed information on mailing list subscription. |
|
From: Werner G. K. <wer...@ya...> - 2000-05-12 21:12:58
|
In response to a user request, GNU Queue is now an approved project on VA Linux's Sourceforge site, http://www.sourceforge.net . I would encourage those of you that don't yet have a Sourceforge login to obtain one. In addition to the eventual CVS repository (not yet fully set up), there's a bug tracker, support tracker, and public discussion forum, amongst other features, all of which can be independently administered or moderated by GNU Queue developers. A login also lets you participate more fully in the broader activities at Sourceforge. I've also moved the mailing lists to Sourceforge to take advantage of their GNU Mailman mailing list software. This is essentially a test message for the new listserver at SourceForge. Because it doesn't support "tips", which has less than five characters, I've had to rename it "developers", so the queue-tips email list has become the queue-developers email list on sourceforge (que...@li...). By utilizing a standard interface for project development, our presence on SourceForge should make it easier for OpenSource developers working on other projects to lend a hand with GNU Queue. Obviously, there's a lot of work still to be done. The GNU Queue web page makes no mention of SourceForge as of yet, and the CVS tree needs to be moved to SourceForge as well. Community participation will be important in making the GNU Queue pages on Sourceforge useful. I encourage all of you to check out the GNU Queue Project Summary page on http://www.sourceforge.net. Use the Sourceforge interface to volunteer to become a developer for GNU Queue, if you're not one already. Note everything is coding; we're looking for people to help us just maintaining bug or support requests as they come in (and they will start coming in eventually.) Have a look around at GNU Queue and the other projects in development on SourceForge. While you're on Sourceforge, you may wish to complete the GNU Queue user survey on Sourceforge. The results of the survey will be posted as it comes in on SourceForge. As always, let me know what you think, either here or in the new Queue public forums on SourceForge! |
