queue-developers

[Queue-developers] patch for compilation in Debian unstable

[Jordi B. C. <jbu...@oc...>]

Hi,

the head of the repository at 
-d:pserver:ano...@cv...:/cvsroot/queue
didn't compile for me. I had to do a few of changes, which are:

* put some long strings separated by a newline without "" into several pieces 
properly surrounded by ""
* make the childsigh void f(int)  as bigsigh() (and as expected by sa_handler)
* substituted deprecated sys_errlist by strerror
* declared mtos() in the .h file so the compiler doesn't get confused

To apply them, use
  patch -p1 < queue.patch
in the queue root directory.

Also, it would probably be a good idea to have something like the autogen.sh 
file I'm attaching in the repository.

cheers,
jordi

Re: [Queue-developers] Activity?

[Mike C. <da...@ix...>]

On Wed, May 12, 2004 at 07:23:28PM -0400, Raymond Page wrote:
> Hi,
> 
> I'm curious if anyone is working on this project or knows much about 
> it.  I'm currently looking for the functionality this package provides, 
> however I can't get the package to build on my system.  I'm not looking 
> for support with that, I'm curious if there's any patches or more recent 
> versions than the 2001 1.4 beta.
> 
> Also, is this list even active?

Yes it is.

You should find that the CVS version from SF is in better shape as far as
compilation goes.

However, there are some known issues with it:

All of the tty stuff is ripped out with intent on rewriting it.
It's currently trivial to get into a dead-locked state, and so the protocol
needs some serious rework.  If you don't expect to have a flood of jobs
submitted in a very short time (things like 10 jobs within 1 second, for
instance), you're probably ok.

So, if you don't need tty support, and you will slowly be submitting long
running jobs, CVS version might just work for you.

I've recently switched jobs and getting up to speed there has severely cut
into my spare time, but that is starting to settle down now.  Working on
Queue has actually managed to bubble up again on my list.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Queue-developers] Activity?

[Raymond P. <pa...@uf...>]

Hi,

I'm curious if anyone is working on this project or knows much about 
it.  I'm currently looking for the functionality this package provides, 
however I can't get the package to build on my system.  I'm not looking 
for support with that, I'm curious if there's any patches or more recent 
versions than the 2001 1.4 beta.

Also, is this list even active?

--
Raymond Page

[Queue-developers] Re: business model & GQ NOT dormant.

[John M. T. Jr. <jo...@ca...>]

Hi,

When I used the phrase "the market is wide-open for a good, solid
queuing product", I merely meant something like "the set of potential 
users of such a tool is large", or "(I think) there is a large pent-up 
demand for such a tool". How it is paid for, or not, and who does the 
work, or not, were intentionally not mentioned by me.

In my experience code created and maintained by folks who are doing it 
for love of the game is simply of better quality than code that is done 
by folks "only" because it is their job. There are exceptions both ways, 
to be sure, but in most fields of endeavor this is true, and it is true 
in software, too. There is a sweet spot where you have a developer who 
also loves writing software...their avocation also happens to be their 
vocation...they are not coding by day only to subsidize their real 
passion, which is something completely tangential to coding (not that 
anything is *completely* tangential to coding :) )

Now how to pay for the web site, the broadband connection, the new 
computer, and all the rest: that is another issue altogether. And, for a 
potential user, deciding whether to run their mission critical project 
on some software written by a bunch of strangers on the Internet - that 
is another issue, too.

Most all open source projects are struggling with these same questions, 
so at least we are in good company.

-- johnT


wernerkrebs wrote:
> Two things:
> 
> 1.
> 
> In fact, GQ hasn't gone dormant.
> 
> If you take a look at http://www.gnuqueue.org, you'll
> see that Mike's been pretty active in the CVS
> repository.
> 
> Of course, as Eric S. Raymond points out in his famous
> essay "The Cathedral and the Bazaar", in proprietary
> software one only wants to a release when everything
> is "perfect", whereas in Open Source development one
> should "release early, release often." 
> 
> One can put out frequent development releases that are
> just snapshots of the latest tarball, even when things
> are not exactly perfect.
> 
> Which is sort of what the world expects, which is why
> people think GQ is dormant. We're working on Mike to
> make him a convert, and maybe we'll get a development
> release that's a tarball snapshot.
> 
> That way, he'll get the credit he deserves for all the
> hard work he's been putting into this behind the
> scenes.
> 
> 2.
> 
> You mention "market."
> 
> Some of the really successful open source projects
> have come up with business models, enabling them to
> get salaried programmers to work on the code.
> 
> There are a number of models. A business can see the
> code base as a critical piece of its infrastructure,
> and donate its own maintainance efforts to the Net. If
> enough companies do this, an informal consortium of
> cost-sharing companies becomes a formal consortium.
> The Apache consortium started this way, and then IBM
> came along and, I believe, actively funded the
> consortium and optimized the NT port in exchange for
> use of the code in some of its products, I think.
> 
> TI (or its subsidy Alantro) wanted to make GQ into a
> software license system. I convinced them to modify
> that in to a central resource control system for GQ,
> which is now an optional part of the code base. So
> that sort of happened for GQ.
> 
> In other models, the authors publish a book on the
> software, and use royalties from the book to support
> programming and marketing efforts.
> 
> Still another model, which might work for GQ, is that
> an optional component is sold as proprietary, and this
> is used to support the free, Open Source component.
> For GQ, these could be fancy GUIs that allow
> centralized control of large cluster, enhanced GQ
> versions optimized for large clusters, or NT versions
> "compatible" with the Unix cluster system. These
> proprietary versions would create a revenue stream to
> enhance the free, Open Source versions, which, in
> turn, would create a larger potential user base for
> the for-pay versions.
> 
> Currently, our "business model" is (almost) entirely
> volunteer. Although some companies have contributed
> code and bug-fixes developed by for-pay programmers,
> Mike isn't getting paid for his efforts.
> 
> It would be great if we could have a salary for Mike,
> or people under Mike somehow, but this is sort of the
> model we're stuck with for now. 
> 
> (Maybe this will change with the next development
> release once more people learn of the many
> behind-the-scenes improvements Mike has made. >;->).
> 
> 
>>John McKowen Taylor, Jr. wrote:
>>
>>
>>
>>>and GQ might as well be it!
>>>
>>>Please let me know if you have any questions or
>>>comments.
>>>
>>
>>Comment:
>>   "the market is wide-open for a good, solid
>>queuing product"
>>   Amen.  Ain't that the truth, brother.
>>
>>John, I am looking forward to the results of your
>>efforts.  It is 
>>regretable that GQ has gone dormant.  Hopefully your
>>efforts and 
>>enthusiasm may yet breathe new life into the old
> 
> girl.
> 
>>Best wishes from one of the non-coders.
>>
>>   -Buckley
> 
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> https://lists.sourceforge.net/lists/listinfo/queue-developers
> 
> 

[Queue-developers] business model & GQ NOT dormant.

[wernerkrebs <wer...@ya...>]

Two things:

1.

In fact, GQ hasn't gone dormant.

If you take a look at http://www.gnuqueue.org, you'll
see that Mike's been pretty active in the CVS
repository.

Of course, as Eric S. Raymond points out in his famous
essay "The Cathedral and the Bazaar", in proprietary
software one only wants to a release when everything
is "perfect", whereas in Open Source development one
should "release early, release often." 

One can put out frequent development releases that are
just snapshots of the latest tarball, even when things
are not exactly perfect.

Which is sort of what the world expects, which is why
people think GQ is dormant. We're working on Mike to
make him a convert, and maybe we'll get a development
release that's a tarball snapshot.

That way, he'll get the credit he deserves for all the
hard work he's been putting into this behind the
scenes.

2.

You mention "market."

Some of the really successful open source projects
have come up with business models, enabling them to
get salaried programmers to work on the code.

There are a number of models. A business can see the
code base as a critical piece of its infrastructure,
and donate its own maintainance efforts to the Net. If
enough companies do this, an informal consortium of
cost-sharing companies becomes a formal consortium.
The Apache consortium started this way, and then IBM
came along and, I believe, actively funded the
consortium and optimized the NT port in exchange for
use of the code in some of its products, I think.

TI (or its subsidy Alantro) wanted to make GQ into a
software license system. I convinced them to modify
that in to a central resource control system for GQ,
which is now an optional part of the code base. So
that sort of happened for GQ.

In other models, the authors publish a book on the
software, and use royalties from the book to support
programming and marketing efforts.

Still another model, which might work for GQ, is that
an optional component is sold as proprietary, and this
is used to support the free, Open Source component.
For GQ, these could be fancy GUIs that allow
centralized control of large cluster, enhanced GQ
versions optimized for large clusters, or NT versions
"compatible" with the Unix cluster system. These
proprietary versions would create a revenue stream to
enhance the free, Open Source versions, which, in
turn, would create a larger potential user base for
the for-pay versions.

Currently, our "business model" is (almost) entirely
volunteer. Although some companies have contributed
code and bug-fixes developed by for-pay programmers,
Mike isn't getting paid for his efforts.

It would be great if we could have a salary for Mike,
or people under Mike somehow, but this is sort of the
model we're stuck with for now. 

(Maybe this will change with the next development
release once more people learn of the many
behind-the-scenes improvements Mike has made. >;->).

>John McKowen Taylor, Jr. wrote:
>
>
>> and GQ might as well be it!
>>
>> Please let me know if you have any questions or
>>comments.
>>
>
>Comment:
>    "the market is wide-open for a good, solid
>queuing product"
>    Amen.  Ain't that the truth, brother.
>
>John, I am looking forward to the results of your
>efforts.  It is 
>regretable that GQ has gone dormant.  Hopefully your
>efforts and 
>enthusiasm may yet breathe new life into the old
girl.
>
>Best wishes from one of the non-coders.
>
>    -Buckley




__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [Queue-developers] Gnu Queue: new developer - me!

[John M. T. Jr. <jo...@ca...>]

Hi Buckley,

Thanks for the kind remarks!

Here's hoping we can get this thing spun back up
and back online!

best regards,

-- johnT

Buckley Collum wrote:
> John McKowen Taylor, Jr. wrote:
> 
>>
>> I think the market is wide-open for a good, solid queuing product -
>> and GQ might as well be it!
>>
>> Please let me know if you have any questions or comments.
>>
> 
> Comment:
>    "the market is wide-open for a good, solid queuing product"
>    Amen.  Ain't that the truth, brother.
> 
> John, I am looking forward to the results of your efforts.  It is 
> regretable that GQ has gone dormant.  Hopefully your efforts and 
> enthusiasm may yet breathe new life into the old girl.
> 
> Best wishes from one of the non-coders.
> 
>    -Buckley
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN's Audience Survey.
> Help shape OSDN's sites and tell us what you think. Take this
> five minute survey and you could win a $250 Gift Certificate.
> http://www.wrgsurveys.com/2003/osdntech03.php?site=8
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> https://lists.sourceforge.net/lists/listinfo/queue-developers
> 
> 

Re: [Queue-developers] Gnu Queue: new developer - me!

[Buckley C. <bu...@me...>]

John McKowen Taylor, Jr. wrote:

>
> I think the market is wide-open for a good, solid queuing product -
> and GQ might as well be it!
>
> Please let me know if you have any questions or comments.
>

Comment:
    "the market is wide-open for a good, solid queuing product"
    Amen.  Ain't that the truth, brother.

John, I am looking forward to the results of your efforts.  It is 
regretable that GQ has gone dormant.  Hopefully your efforts and 
enthusiasm may yet breathe new life into the old girl.

Best wishes from one of the non-coders.

    -Buckley

[Queue-developers] Gnu Queue: new developer - me!

[John M. T. Jr. <jo...@ca...>]

Hi,

Werner just added me as a developer to Gnu Queue,
and I'd like to take a moment to introduce myself.

My name is John Taylor,
I work at Cadence Design Systems, Inc., in Cary, NC.
I have been programming in C and C++ since sometime in the 80s,
and my primary platforms are Linux and Solaris,
with side trips to Windows, DOS, and PalmOS.

We recently bought a bunch of IBM Xeon and Opteron 1u
servers, and my first reflex was to load DQS on them,
which I used to use on Suns.
Alas, DQS is no more, so I started looking at what the net
had to offer. Constraints were 1. Open Source, 2. Free, as in beer.

This quickly ruled out
   LSF (no source, $$$),
   Condor (weird licensing),
   Sun "GridWare" (formerly Codine, formerly DQS, weird licensing, no 
source),
   and a couple of others.

Gnu Queue and GNQS emerged on top, to me.

Gnu Queue's cool rsh-like facility really set it apart from the others.

But when I went to download and compile it on RH8,
I couldn't!

And when I went to subscribe to the mailing lists,
I couldn't!

And when I examined the file dates, they were ancient!

Assuming there was still life in the project,
and noticing that people are still sending emails to the lists,
I decided to try to get Gnu Queue useful to me -
and that's why I am here.

I am not sure how much impact I will have,
or how much time I can commit,
but my goal is to get GQ into shape so that I can simply
download and compile it on my RH8 & RH9 and Solaris 8 & 9 machines.
Beyond that, who knows?
I think the market is wide-open for a good, solid queuing product -
and GQ might as well be it!

Please let me know if you have any questions or comments.

Thanks!

best regards,

-- johnT
John McKowen Taylor, Jr.
Cadence Design Systems, Inc.
200 Regency Forest Dr.
Cary, NC 27511 USA
+1 919 481 6835

RE: [Queue-developers] manage a tool license as a resource?

[Werner K. <wk...@sd...>]

A subset of TI, Alantro, developed a module for GQ that was intended,
ultimately, to be used with a license manager.

This is the queue_manager package, which can be turned on in ./configure
(./configure --enable_manager=YES)

This sets up a centralized server than monitors the Queue demons cluster
wide via an SQL server (there are free ones---Postgresql comes to mind---
as well as another famous SQL server that's not quite free.)

The queue_manager monitors the number of a particular that is running,
and can enforce limits on that.

Alantro's idea was to GQ together with their monitoring software to ensure
that licensed programs were registered with GQ, could only be run in a
monitored queue, and thus basically used GQ as a license manager.

They were worried about the political ramifications of use a GNU program
for license management, since that implies non-free software. However, I
persuaded them that the GNU community would certainly welcome a central
protocol that enforced other limits as well (eg resource limits) and
that's what queue_manager does.

The docs are in doc/queue_manager .
--
Werner G. Krebs, Ph.D.,
San Diego Supercomputer Center MC 0527
University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093-0527, USA

On Fri, 10 Jan 2003, Pelletier, Bradley wrote:

> Thanks!!
>
> I have already checked that the tool can release and recover its license by
> sending signal 20 to release & signal 18 to recover.
>
> But to be more specific I want to release the license from a process that
> some
> body else owns.
>
>
>
>
> -----Original Message-----
> From: Sam Liddicott [mailto:Sam...@le...]
> Sent: Friday, January 10, 2003 3:34 AM
> To: 'Pelletier, Bradley'; que...@li...
> Subject: RE: [Queue-developers] manage a tool license as a resource?
>
>
> It depends entirely on how the licensed software manages it's license
> verification.
>
> The first step I imagine would be to check with the vendor whether or not it
> is permissable to interrupt a process and hand the license to another
> process and then later continue the first process; this procedure has little
> to do with GNU queue.
>
> If the procedure is possible them I am sure gnu queue (or even ssh -c) could
> be made to use it with a little /bin/sh glue.
>
> Sam
>
> > -----Original Message-----
> > From: Pelletier, Bradley [mailto:BPe...@ch...]
> > Sent: 09 January 2003 22:55
> > To: 'que...@li...'
> > Subject: [Queue-developers] manage a tool license as a resource?
> >
> >
> >
> >
> > Can I use GnuQue to manage a license resource?
> >
> >  I want to temporally release a license, start and complete a
> > new job, then
> > grab the license and continue with the 1st job.
> >
> >
> >
> > Bradley L. Pelletier
> > Principal Engineer
> > ChipWrights Inc.
> > 2150 Washington St
> > Newton, MA 02462
> > Tel	1.617.928.3140
> > Fax	1.617.928.0674
> > www.chipwrights.com
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Queue-developers mailing list Que...@li...
> > To unsubscribe, subscribe, or set options:
> > https://lists.sourceforge.net/lists/listinfo/queue-developers
> >
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> https://lists.sourceforge.net/lists/listinfo/queue-developers
>

RE: [Queue-developers] manage a tool license as a resource?

[Pelletier, B. <BPe...@ch...>]

Thanks!!

I have already checked that the tool can release and recover its license by
sending signal 20 to release & signal 18 to recover.

But to be more specific I want to release the license from a process that
some
body else owns.




-----Original Message-----
From: Sam Liddicott [mailto:Sam...@le...]
Sent: Friday, January 10, 2003 3:34 AM
To: 'Pelletier, Bradley'; que...@li...
Subject: RE: [Queue-developers] manage a tool license as a resource?


It depends entirely on how the licensed software manages it's license
verification.

The first step I imagine would be to check with the vendor whether or not it
is permissable to interrupt a process and hand the license to another
process and then later continue the first process; this procedure has little
to do with GNU queue.

If the procedure is possible them I am sure gnu queue (or even ssh -c) could
be made to use it with a little /bin/sh glue.

Sam

> -----Original Message-----
> From: Pelletier, Bradley [mailto:BPe...@ch...]
> Sent: 09 January 2003 22:55
> To: 'que...@li...'
> Subject: [Queue-developers] manage a tool license as a resource?
> 
> 
> 
> 
> Can I use GnuQue to manage a license resource?
> 
>  I want to temporally release a license, start and complete a 
> new job, then
> grab the license and continue with the 1st job.
> 
> 
> 
> Bradley L. Pelletier
> Principal Engineer
> ChipWrights Inc.
> 2150 Washington St
> Newton, MA 02462
> Tel	1.617.928.3140
> Fax	1.617.928.0674
> www.chipwrights.com
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Queue-developers mailing list Que...@li...
> To unsubscribe, subscribe, or set options:
> https://lists.sourceforge.net/lists/listinfo/queue-developers
> 

[Queue-developers] manage a tool license as a resource?

[Pelletier, B. <BPe...@ch...>]

Can I use GnuQue to manage a license resource?

 I want to temporally release a license, start and complete a new job, then
grab the license and continue with the 1st job.



Bradley L. Pelletier
Principal Engineer
ChipWrights Inc.
2150 Washington St
Newton, MA 02462
Tel	1.617.928.3140
Fax	1.617.928.0674
www.chipwrights.com

[Queue-developers] Introduction

[Mike C. <da...@ix...>]

Hello.

As most of you know, I have volunteered to become the new GNU Queue
maintainer.

My apologies for taking so long to make my announcement.  In retrospect,
I probably should have written something sooner, but I did want to put
my full attention into this announcement.

In mid-June, when Werner first announced that he felt he no longer has
the time to give Queue the attention it deserves, I toyed with the idea
of taking over.   I had just started a large, time-consuming personal
project, and thought that if, when I finished it, if no one else had yet
taken over, I'd see what I could do.  Not too long later, though, Richard
Stallman put out a feeler on the info-gnu mailing list, and I decided
to throw my hat in the ring, even though I wasn't quite in a favorable
position yet.  Things progressed a bit faster than I had anticipated, and
in early July, RMS selected me to take over.  It wasn't until late-August,
however, that I had time to actually start the actual work on taking
over Queue.  The large-time consuming part of my personal project is over,
and now I have the time to concentrate on Queue.  [One would think that
being unemployed, you'd have more time on your hands!]

If I remember correctly, I first became interested in Queue when someone
posted about portability of tty settings/changes across platforms.
I have been following Queue development off and on since.

My personal use for Queue is across my home network of a bunch of Linux
based boxes at home, maybe expanding to using Cygwin.

In a recent email, Werner commented on the differing opinions on what
Queue should be.   The comment about simplicity is somewhat amusing, as
that is what appeals to me.  At one point, when having difficulties with
getting Queue to work, I wrote a bunch of shell scripts that I called
the Simple Queuing System.  So I guess that probably gives a hint at
which direction I would tend, but is certainly no guarantee that is the
direction I will go.

There are a lot of other points that Werner brought up in his
introduction, such as IPv6 support and client-server v. peer-peer,
for example, that I need to get up to speed on.

My current short term plans are this:

1) Review the code base and make sure I'm familiar with all of the
elements in the package.

2) Review all of the messages on the multiple queue-* lists to make sure
I know all of the current issues.

3) Familiarize myself with the facilities that SourceForge has to offer,
and see how they are currently being used within the project.

4) Look at the tools necessary to product a release and make sure there
is suitable access to correct versions (I tend to run bleeding edge on
all of my tools, which may not be acceptable).  I'm talking about things
like auto* tools and the such here.

After I know that I can package a release, I will probably do another
beta release, if with no other changes than current CVS plus contact
information changes.  Then start work towards an official release.

Longer term plans are a bit more up in the air.

Some things I'd personally like to see would be (in no order):

+ Better cross-platform capabilities.  For example, I'm not sure on the
current status of load determination, sharing determination of load,
tty capabilities, and so on.  They might all be fine, but I want to
verify that.  It _might_ be a case where something like XML-RPC would be
a good solution.  If XML did become introduced in the package, it would
probably make since to turn the configuration files into something XML
capable as well.

+ Library support.  I would really like to be able to use Queue and GNU
Make together transparently and do something like 'make -j' across all
available machines.  I would imagine it should be possible to create an
API that can be linked in.

+ Resource allocation facilities.  Extend the spooldir notion to identify
arbitrary resources, and a client can specify that it is going to use
those resources and scheduling can occur as appropriate.

Can't think of anything else to say at the moment.

Unsurprisingly, I will probably pester Werner quite a bit as things
progress.

Meanwhile, must now go entertain the munchkin while an SO fixes dinner.

Cheers,
mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

[Queue-developers] More on new maintainer

[Werner K. <wk...@SD...>]

I think Mike's still getting acclimated to being the new GNU Queue
maintainer.

Both RMS and I fully support Mike. However, I think the best for the GNU
Queue community is not to do what I want to do, or what RMS wants to do,
what Mike wants to do, but what the GNU Queue community feels is in its
best interests. That's basically the idea of democracy, and we haven't had
enough of it around in the world of late IMHO, although this is a separate
topic for another list.

In the short term, Mike is the maintainer because RMS and I say he is.

In the longer term, however, I think that the standard should be that the
GNU Queue maintainer is whoever the GNU Queue community recognizes as the
GNU Queue maintainer.
That doesn't always mean making everyone happy (this is volunteer work,
people have real lives where they actually put the bread on their tables,
after all, and my understanding is --- RMS correct me if I'm work --- that
Mike was the only qualified person who really wanted this job), but it
does mean that the maintainer should take public responsibility for the
project and act in GNU Queue-maintainer like way.

And so, ultimately you, the GNU Queue community, must decide, over the
longer term (next few months) whether or Mike is your maintainer,
keeping in mind that it can, at times, be a difficult job and that there
hasn't been a long list of volunteers. I have also
found it a very rewarding and educational experience, so I hope that, as
Mike begins to take over the reins, more people will come forward and
volunteer to assist him. Perhaps, years from now, if the community grows
large enough, there could even be some sorts of informal email voting as
other Open Source projects have.

I hope that the GNU Queue community will provide every assistance to Mike
or whoever else you decide, at some point in the
future, should be the maintainer.

I've given Mike all of the keys necessary to be the GNU Queue maintainer,
including issue new releases, moderate the SourceForge forums, write to
the CVS repository, edit the on-line documentation, and post on all the
mailing lists, including queue-announce. Once I'm satisfied
he's fully accepted by the community (if only grudgingly) I will
irrevocably turn over the remaining few in a few weeks or so. For now,
however, suffice it to say he has my full support.

There are some things that I think would be helpful. I hope, after
becoming acclimated,
Mike will give us a very brief, or even a long, introduction to himself
and his goals or philosophy as the new maintainer and ask for the support
of the community in accomplishing those goals.

I haven't very much email contact with Mike since he came forwarded about
a week ago (I suppose he is a busy man), so I'm curious to learn of this
philosophy myself, and whether
or not there are any radical changes and new ideas in store for us. :-)

I still get emails from users occasionally because my email address is
listed in the source. I suppose one of the first that will need
eventually to be done is to issue a new release with Mike's email listed
as the maintainer. (The source actually asks for correspondence to go to
bug-queue which is currently being forwarded to queue-support; Mike might
want to change this and have bug-queue forward to him directly. The FSF
people can do this for him.)

A user requested that some of old compile bugs that have bitting sitting
on Sourceforge be fixed in a new release; that's up to Mike.

In any event, once again, please welcome Mike and provide
with any assistance, suggestions, and support
as he begins this challenging, albeit rewarding, task as
your new maintainer
 --
Werner G. Krebs, Ph.D.
Postgraduate Researcher
Integrative Biosciences
San Diego Supercomputer Center MC 0527
University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093-0527, USA

Re: [Queue-developers] GNU Queue development alive and well? (help needed with RH7.2 and 7.3)

[Werner G. K. <wer...@ya...>]

Sven Hartrumpf <Sve...@Fe...> writes:

> On 7 Aug 2002, Lou Estey <lo...@un...> wrote:
> > We run GNU queue in a very limited way, with jobs looking like:
> >
> > queue -i -w -h <DNSname> -- <job>

> ssh should suffice for things like that.

> You might have to use cd in the <job> part and you
> might need to setup ssh so that you can login with ssh without
> a password, e.g. by using SSH keys:
> http://freshmeat.net/projects/ssh-with-keys-howto/

> Greetings
> Sven

When GQ was first developed, of course, ssh did not exist. Later, ssh became
a commercial product, and then eventually OpenSSH was born.

I personally liked to use GQ on my cluster in place of rsh because the
interface was more convenient and GQ was faster than rsh.

Once ssh became popular, it was often suggested that OpenSSH code be merged
into GQ (or vice versa) so that GQ would be a substitute for SSH with SSH
security. Eventually tarrif rules on cryptography were repealed, so this
became an attractive possibility but I never got around to do this. It's not
clear, of course, whether with SSH security GQ would be as fast as it is
without security. Then again, machines have become much faster, so starting
jobs with SSH libs might not be noticable different from current GQ
protocols, and only those concerned with benchmark will note the difference.

It feels good to be a peyon on this list and let someone else (our new
maintainer!) worry about which way to take GQ.

I'm still waiting for the introductory speach. I'm expecting Mike to write
something like "Friends, Romans, GQers, lend me your ears! I have come to
bury the previous maintainer, not to praise him." :-) Well, maybe not quite.
But I can't wait to see what GQ will look like in a year or so under new
management.

[Queue-developers] New GNU Queue maintainer

[wernerkrebs <wer...@ya...>]

Good news!

Mike Castle (da...@ix...) has volunteered to
become the new GNU Queue maintainer!

GNU Queue is once again an active project! 

From his homepage (www.netcom.com/~dalgoda/) it sounds
like he is a very competent system administrator, so I
think we are in very good hands here and look forward
to seeing what Mike can and will do with GNU Queue.

I suppose the thing to say right off the bat is that
I'm not sure how familar Mike will be with some of the
discussions I've had on and off-line with many of you
regarding GQ's features. 

There have been some widely differing opinions. 

The Debian people, for example, stress reliability and
low-latency (which we tried to do when go rid of the
NFS protocol). Other people would like a very simple
project (perhaps even a shell script). Others want
interactive load balancing and minimal end-user
training via the proxy interface (our strong point).
Others wanted installation by non-root users. The
Internet Draft people wanted an Internet-wide protocol
that would be highly scalable, be IPv6 compatible and
work across NAT boxes (and this can be to some extent
because we have a peer-to-peer protocol; if it's made
non-deterministic and keeps track of its network
neighbor's responses, it can be made extremely
scalable. Going across NAT boxes with IPv4 is another
matter, although that can be tackled as well. The
Texas Instrument/Alantro people wanted centralized
control, and they wanted a client-server and
SQL-database protocol, which they added but which
hasn't been popular. Some people wanted Free process
migration in various forms, which we added. Others
have complained about the documentation and how that
should look. And so on.

So, I hope you'll get Mike up to speed with your
latest opinions on what GQ should look like going into
the future as I think that will be a tremendous help
to him.

Mike ... take it from here!
--
Werner G. Krebs, Ph.D.
Postgraduate Researcher
Integrative Biosciences
San Diego Supercomputer Center MC 0527
University of California, San Diego
9500 Gilman Drive
La Jolla, CA 92093-0527, USA
+1 858 822 3620

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [Queue-developers] GNU Queue development alive and well? (help needed with RH7.2 and 7.3)

[Sven H. <Sve...@Fe...>]

On 7 Aug 2002, Lou Estey <lo...@un...> wrote: 
> We run GNU queue in a very limited way, with jobs looking like:
> 
> queue -i -w -h <DNSname> -- <job>

ssh should suffice for things like that.

You might have to use cd in the <job> part and you
might need to setup ssh so that you can login with ssh without
a password, e.g. by using SSH keys:
http://freshmeat.net/projects/ssh-with-keys-howto/

Greetings
Sven

[Queue-developers] GNU Queue development alive and well? (help needed with RH7.2 and 7.3)

[Lou E. <lo...@un...>]

Hi (any GNU Queue developer),

We have been running GNU Queue (queue-1.30.1) on a http RedHat
x86 server cluster for about a year now.  Over the last week
I've been getting a replacement server with RH7.3 configured
with the last step being the installation and successful
running of queue-1.30.1 or queue-1.40.1beta -- with not much
luck.  Upon checking with SourceForge, I noticed that Werner Krebs
was bowing out, there hasn't been much discussion on
GNU Queue development since about mid-2001, and nobody's responded
to the last several questions posed on the SourceForge
Open Discussion forum.  Werner suggested looking at GNQS, but at:

http://www.gnqs.org/oldgnqs/docs/starter_pack/alternatives/

and other pages at the GNQS site it sounds like its primary
developer is bowing out as well and is pushing GNU Queue as
the alternative!

We run GNU queue in a very limited way, with jobs looking like:

queue -i -w -h <DNSname> -- <job>

from the http server to one of the other RedHat x86 nodes
i.e. we aren't interested in automatic average load-balancing,
because the server keeps track of when these specific jobs are
completed so we can immediately reuse the fastest CPU available.
Thus Werner's suggestion of Mosix and Condor (which, admittedly,
I've just poked around on the Web sites), which sound primarily
like just batch and load-balancing queueing, don't seem to
mesh with our requirements.  GNU Queue also preserves the current
working directory and user ID, which turns out to be very handy
for us.  Needless to say, we'd really like to see GNU Queue be
alive and well, and would like help getting GNU Queue going on
Redhat 7.2 and 7.3.

So, is there anybody out there still working on or interested in
working on GNU Queue?

If so, what's the status on Linux?  I don't understand the code
in detail, but can provide copious testing on RedHat 7.1, 7.2 and
7.3  (and our original 6.2 system while it's still up).

If, on the other hand, GNU Queue development is dead (at least
for a while), someone ought to write a definite email to
SourceForge, so that

http://sourceforge.net/projects/queue/

really reflects the current status.

cheers,
--lou

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Louis H. Estey, Ph.D.              office:  [+001] 303-497-8036      
UNAVCO/GST/UCAR, P.O. Box 3000        FAX:  [+001] 303-497-8028
Boulder, CO  80307-3000            e-mail:  lo...@un...
   websites: http://www.gst.ucar.edu http://www.unavco.ucar.edu

"If the universe is the answer, what is the question?"
                                               -- Leon Lederman
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Queue-developers] Dropping support for GNU Queue

[wernerkrebs <wer...@ya...>]

Dear GNU Queue community,

It has been a great pleasure serving as your
maintainer. It has been a rewarding although very
time-consuming activity.

Recently, I've made the decision more or less to stop
supporting Queue, at least for now, because of job
responsibilities in the real world and lack of time.

A number of non-commercial and commercial packages use
GNU Queue for load-balancing facilities. If you
require support for GNU Queue in connection with these
packages, I suggest you contact the distributors of
these packages for support with GNU Queue.

There are a number of other excellent load-balancing
and process migration packages available that are Open
Source or quasi-Open Source. These include GNQS,
Mosix, Condor, as well as a number of load-balancing
packages available from the San Diego Supercomputer
Center.

If you know of any one interested who might make a
good maintainer for GNU Queue, please let me know.

In the meantime, please check out the discussions on
Sourceforge; there are some members of the community
supporting GNU Queue.

http://www.gnuqueue.org.
--
Werner G. Krebs, Ph.D.,
Integrative Biosciences,
San Diego Supercomputer Center MC 0527
University of California, San Diego MC 0527
9500 Gilman Drive
La Jolla, CA 92093-0527, USA


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Queue-developers] Getting info. about a waiting job

[Satyajit B. <be...@fn...>]

Hi,

I am a new queue user and want to know a way to get information about
a waiting job. Is there a command-line option or something? Another
thing is for queue to limit number of jobs do all the jobs have to be
submitted using queue? Since queue checks system resources before
executing a spooled job I'd expect it to work even if some already-running
jobs have not been submitted using queue. I'd appreciate any feedback
regarding this at be...@fn....

Thanks,
Satyajit

Re: [Queue-developers] Queue on Solaris 8: solutions and problems

[Tim B. <buc...@IS...>]

On Tue, 2001-10-30 at 07:58, Henry Tillotson wrote:


> 2) Also in the Makefile, there is a line:
> 
>           cp doc/queue.man doc/queue.1
> 
>    This is trying to create a file doc/queue.1 in the queue-1.30.1, which
>    is in my user area... since the make is run as root, this fails trying
>    to write to the user area... I notice that Linux seems to let root write
>    into a user area, regardless of permissions... Solaris does not. I resolved
>    this by performing the copy separately (under my user account), and deleting
>    this line from the makefile. The attached diff for Makefile.in also does this
>    job.

This is not a Solaris problem.  It's a filesystem (most likely NFS)
problem.  My guess is that your home directory is NFS-mounted from
another machine.  That other machine probably has the "root squash"
option to NFS turned on.  NFS does this by default on both Solaris and
Linux.

In any case, "make install" isn't the time to be creating files in the
source directory.  The file should be created at the same time the
program is compiled, or even better, just installed directly into its
final location rather than making a pointless copy of it in the source
directory.


-- 
Tim Buchheim

[Queue-developers] Queue on Solaris 8: solutions and problems

[Henry T. <cc...@uc...>]

Hi all,

I've succeeded in installing and running queue-1.30.1 on a Solaris 8
system (using the native Sun cc compiler), and thought it would be useful
to share the fixes I found necessary. I haven't yet been able to get
queue-1.40.1beta to compile.

1) The main problem with the cc compile on Solaris is the fact that the
   compiler flag -Wp,-MD, doesn't work properly. This flag appears in the
   Makefile template Makefile.in, e.g.:

          $(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $<

   The -Wp part says "pass the following option through to the
   pre-processor"... the subsequent part -MD,.<filename> means "generate
   a list of the make dependencies of this source file, placing it in
   <filename>".

   Unfortunately, the Solaris form of this option doesn't seem to work
   in the same way. The only way that I've found to generate these
   dependencies is to use the COMPILER option -xM, which runs the
   pre-processor ONLY, sending the dependencies to standard output.

   This means that the single line above needs to be replaced with TWO
   lines, one to generate the dependencies, and one to do the compilation,
   e.g.:

          $(COMPILE) -xM $<  > .deps/$(*F).pp
          $(COMPILE) -c $<

   The diff file for Makefile.in, included below, makes the changes in the
   four places necessary.

2) Also in the Makefile, there is a line:

          cp doc/queue.man doc/queue.1

   This is trying to create a file doc/queue.1 in the queue-1.30.1, which
   is in my user area... since the make is run as root, this fails trying
   to write to the user area... I notice that Linux seems to let root write
   into a user area, regardless of permissions... Solaris does not. I resolved
   this by performing the copy separately (under my user account), and deleting
   this line from the makefile. The attached diff for Makefile.in also does this
   job.

=======start of Makefile.in diff========
416c416,417
< 	$(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
---
> 	$(COMPILE) -xM $<  > .deps/$(*F).pp
> 	$(COMPILE) -c $<
425c426,427
< 	$(LTCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
---
> 	$(LTCOMPILE) -xM $< > .deps/$(*F).pp
> 	$(LTCOMPILE) -c $<
435c437,438
< 	$(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
---
> 	$(CXXCOMPILE) -xM $< > .deps/$(*F).pp
> 	$(CXXCOMPILE) -c $<
444c447,448
< 	$(LTCXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
---
> 	$(LTCXXCOMPILE) -xMD $< > .deps/$(*F).pp
> 	$(LTCXXCOMPILE) -c $<
573d576
< 	cp doc/queue.man doc/queue.1
=======end of Makefile.in diff========

   I haven't investigated how to integrate these changes more fully into queue
   (or even if this is possible).

3) In queued.c, there is a string which is split over two lines: cc doesn't accept
   this. I note that this is fixed in queue-1.40.1beta, but here is my fix for
   version 1.30.1:

=======start of queued.c diff========
4713,4714c4713,4714
< 	merror1("QueueD: Received invalid cookie. In NO_ROOT, COOKIEFILE must be
< the same on all machines! Received cookie: %s\n",tmpcookie); goto abort;
---
> 	merror1("QueueD: Received invalid cookie. In NO_ROOT, COOKIEFILE must be \
>         the same on all machines! Received cookie: %s\n",tmpcookie); goto abort;
=======end of queued.c diff========

4) This isn't really an error, but I found it useful to redirect the "system"
   mail generated by queue to somewhere other than root... in our networked
   environment this is not a specific enough destination. During investigations,
   I re-directed this mail to my own account (ccaahot), with the following fix
   to configure:

=======start of configure diff========
4234c4234,4235
< MIUSER=\"${OWNER}\"
---
> # MIUSER=\"${OWNER}\"
> MIUSER=\"ccaahot\"
=======end of configure diff========

With these fixes, queue seems to work OK on my Solaris 8 machine (a SunBlade 100),
though I haven't done exhaustive tests yet.

I hope this info is of use to someone

cheers

Henry
=====================================================================
Henry Tillotson                  e-mail: h.t...@uc...
User Support                      phone: 020 7679 7827
Information Systems                 fax: 020 7388 5406
University College London, Gower Street, London WC1 E 6BT
=====================================================================

[Queue-developers] queued will not compile on Redhat 7.1 anyone out there have any luck?

[meertens <mee...@qw...>]

Hello,
I submitted this bug report officially to SourceForge, but
have not heard back and thought I would ask
a broader list of queue developers. Thanks
in advance for any help on this.
Chuck

                           Date:
                           2001-08-18 10:45

Priority:

5
                           Submitted By:
                           Chuck Meertens (meertens)

Assigned To:

Nobody/Anonymous (nobody)
                           Category:
                           None

Status:

Open
                           Summary:
                           queued will not compile on Redhat 7.1
                           Hello,
                           I am not able to compile queued (as root) on
a Dell 1.5 ghz P4 Computer
                           with standard Redhat 7.1 installed
("out-of-the-box"). The P4, though relatively new, is
                           officially supported by Redhat 7.1. I get the
same errors with
                           both queue-1.30.1 and queue-1.40.1beta. I am
compiling with gcc with the following version:
                           gcc -v
                           Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
                           gcc version 2.96 20000731 (Red Hat Linux 7.1
2.96-81)

                           The pre-compile step "./configure
--enable-root" appears
                           to run error-free. I was able to compile on a
Dell P2 running Red Hat 6.2 Linux
                           and then copy over the queued executable over
to the P4 machine. queued then
                           installs and runs (after taking out the
queued compile steps in the Makefile). I am therefore
                           up and running with queue! As queue looks
like it will work nicely in our new
                           processing cluster, I am hopeful that a
solution to this problem will be found.
                           Attached below are the details of the errors
that I hope
                           will be useful for de-bugging on-going
development.
                           Chuck M.

                           queue-1.40.1beta]# make
                           gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c
queued.c
                           queued.c:239: warning: `struct tm' declared
inside parameter list
                           queued.c:239: warning: its scope is only this
definition or declaration, which is probably not what
                           you want.
                           queued.c:246: warning: `struct tm' declared
inside parameter list
                           queued.c: In function `runqueue_b':
                           queued.c:3110: storage size of `now' isn't
known
                           queued.c:3110: storage size of `now' isn't
known
                           queued.c:3114: invalid type argument of
`unary *'
                           queued.c: At top level:
                           queued.c:4932: warning: `struct tm' declared
inside parameter list
                           queued.c:4933: conflicting types for
`checktime'
                           queued.c:239: previous declaration of
`checktime'
                           queued.c: In function `checktime':
                           queued.c:4940: warning: passing arg 2 of
`check1time' from incompatible pointer type
                           queued.c: At top level:
                           queued.c:4951: warning: `struct tm' declared
inside parameter list
                           queued.c:4952: conflicting types for
`check1time'
                           queued.c:246: previous declaration of
`check1time'
                           queued.c: In function `check1time':
                           queued.c:4972: dereferencing pointer to
incomplete type
                           (***note this line is: if (strncmp(p,
"SuMoTuWeThFrSa"+tp->tm_wday*2, 2) == 0) ***)
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4972: dereferencing pointer to
incomplete type
                           queued.c:4980: dereferencing pointer to
incomplete type
                           queued.c:4980: dereferencing pointer to
incomplete type
                           queued.c:4984: dereferencing pointer to
incomplete type
                           queued.c:4985: dereferencing pointer to
incomplete type
                           queued.c:4985: dereferencing pointer to
incomplete type
                           queued.c:4987: dereferencing pointer to
incomplete type
                           queued.c:4987: dereferencing pointer to
incomplete type
                           queued.c:4995: dereferencing pointer to
incomplete type
                           queued.c:4995: dereferencing pointer to
incomplete type
                           queued.c:4996: dereferencing pointer to
incomplete type
                           queued.c:4996: dereferencing pointer to
incomplete type
                           queued.c:5004: dereferencing pointer to
incomplete type
                           queued.c:5004: dereferencing pointer to
incomplete type
                           make: *** [queued.o] Error 1

[Queue-developers] A few code fixups ...

[Carl E. <ced...@vi...>]

I found a few things from that I would like to share.
I've included a context diff of my changes.  There
were some places where bitwise operators were used
where I think logical operations were ment plus a
few other small things.

Thanks,
-Carl Edwards
 Vitesse Semiconductor

[Queue-developers] Re: queue problem -- 'queued -D' works

[Buckley C. <Bu...@Me...>]

Hello Werner et al.

Interesting turn of events.
I finally discovered that queued can be run in debug mode.
The interesting thing is that queue will not work unless queued is running
in debug mode.

Running queued normally results in errors such as:
<render0:buckley> /usr/local/queue/bin/queue -i -w -n -v  -- hostname
Requesting load average for queue "now" on host "render0"...
Requesting load average for queue "now" on host "render1"...
Queue: Failed to submit job to queue "now".
<render0:buckley> /usr/local/queue/bin/queue -v -- hostname
Requesting load average for queue "now" on host "render0"...
Requesting load average for queue "now" on host "render1"...
Queue: Failed to submit job to queue "now".

However, running 'queued -D &' results in:
<render0:buckley> /usr/local/queue/bin/queue -v -- hostname
Requesting load average for queue "now" on host "render0"...
Requesting load average for queue "now" on host "render1"...
Trying "render0"...
Going to submit job to queue "now" on host "render0".
queue.c: main(): tty(in/out/err): 1 1 1.
render0
<render0:buckley> /usr/local/queue/bin/queue  -- hostname
render0


So, why must debug be running for queued to work???
I will continue to play with this (and maybe try Monica's stuff soon).

    -Buckley

[Queue-developers] beginning linux

[Buckley C. <Bu...@Me...>]

Hello again.

So, I have decided to hold off on trying both Irix and linux queue until
I at least have the linux compiled version working.

The problem:
I compiled queue-1.40.1beta on linux 2.2.14-12smp, with no substantial
compile errors.
    ./configure --enable-root --prefix=/usr/local/queue
    make
    make install

This set up a box named 'render0'

I also set up a box named 'render1'
    'make -install-exec'

But, things are not working.

<render0:buckley> /usr/local/queue/bin/queue -i -w -h render0 --
hostname
Failed to submit job in queue "now" to host "render0".
<render0:buckley> /usr/local/queue/bin/queue -i -w -h render1 --
hostname
qlib.c Queue_nonblocking_rw(): failed to read() 4 bytes from fd 4:
read(): Connection reset by peer
Failed to submit job in queue "now" to host "render1".

<render0:buckley> /usr/local/queue/bin/queue -i -w -n -- hostname
qlib.c Queue_nonblocking_rw(): failed to read() 4 bytes from fd 4:
read(): Connection reset by peer
Queue: Failed to submit job to queue "now".
<render0:buckley> /usr/local/queue/bin/queue -i -r -n -- hostname
qlib.c Queue_nonblocking_rw(): failed to read() 4 bytes from fd 3:
read(): Connection reset by peer
Queue: Failed to submit job to queue "now".


So, now I must throw myself upon the kindness of Mr. Krebs et al, and
ask if anyone has an idea about how to get this working.
Any help is greatly appreciated.

Once this is under control, I will venture towards Monica's addition.


    -Buckley