Bug#616071: ITP: python-oejskit -- python driven javascript unit testing
Package: wnpp Severity: wishlist Owner: Anders Hammarquist * Package name: python-oejskit Version : 0.9.0 Upstream Author : Open End AB, Samuele Pedroni * URL : http://pypi.python.org/pypi/oejskit * License : MIT Programming Lang: python Description : python driven javascript unit testing jskit contains infrastructure and in particular a py.test plugin to enable running tests for JavaScript code inside browsers directly using py.test as the test driver. Running inside the browsers comes with some speed cost, on the other hand it means for example the code is tested against the real- world DOM implementations. The approach also enables to write integration tests such that the JavaScript code is tested against server-side Python code mocked as necessary. Any server-sideframework that can already be exposed through WSGI (or for which a subset of WSGI can be written to accommodate the jskit own needs) can play along. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302095719.27916.19736.report...@fido.openend.se
Bug#491667: ITP: python-meld3 -- an HTML/XML templating system
Package: wnpp Severity: wishlist Owner: Anders Hammarquist <[EMAIL PROTECTED]> * Package name: python-meld3 Version : 0.6.4 Upstream Author : hris McDonough <[EMAIL PROTECTED]> * URL : http://plope.com/software/meld3/ * License : Zope Public License Programming Lang: Python Description : an HTML/XML templating system meld3 is an HTML/XML templating system for Python 2.3+ which keeps template markup and dynamic rendering logic separate from one another. See http://www.entrian.com/PyMeld for a treatise on the benefits of this pattern. supervisor (see other ITP) depends on this package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491665: ITP: supervisor -- system for controlling process state
Package: wnpp Severity: wishlist Owner: Anders Hammarquist <[EMAIL PROTECTED]> * Package name: supervisor Version : 3.0a6 Upstream Author : Chris McDonough/Agendaless Consulting * URL : http://supervisord.org/ * License : BSD-like (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : system for controlling process state Supervisor is a system for controlling and maintaining process state, similar to what init does, but not intended as an init replacement. It will manage individual processess or groups of processes that need to be started and stopped in order, and it is possible to control individual process state via an rpc mechanism, thus allowing ordinary users to restart processes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ethernet newbee failure
> route add -host 10.1.1.10 dev eth0 > route add -host 10.1.1.20 dev eth0 > > on both machines, the ping still doesn't work, but I get the PKT light on > the hub to blink in time with the pings. This seems to indicate that the > hardware is "doing the right thing". I still think there is something > missing from route... Yes, you want a network route for the ethernet, assuming you stick with the 255.0.0.0 netmask (which is fine unless you plan to use other portions of the 10/8 network elsewhere and want to be able to talk to them from these hosts): route add -net 10.0.0.0 You don't want the host routes you have listed above (I have vague memories of entries like that confusing the ARP code). You should have a line in your routing table like this when it's properly set up: DestGw Genmask Flags MSS Window irttIface 10.0.0.0* 255.0.0.0 U 0 0 0 eth0 /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student | Hem: +46 31 47 69 27 Chalmers University of Technology, G|teborg, Sweden | Mob: +46 707 27 86 87
Intent to create: nfs-client
In order for the kernel nfs daemon to function properly wrt file locking,
clients must be running rpc.statd. I will therefore, as part of moving
knfs to unstable, create a nfs-client package containing rpc.statd.
I plan to include showmount in it as well (with an approproate replaces for
nfs-server), since it is a handy tool on clients as well.
/Anders
--
-- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist | [EMAIL PROTECTED],iko.pp}.se
Physics Student, root, Debian Maintainer| Tel: +46.31.47 69 27
Jag ska b|rja plugga i l{svecka 1...| Cel: +46.707.27 86 87
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
> The patches that I sent you should be completely safe. But the > resulting packages have only been tested by me. (As I said, I took > out the -pedantic flag on the altdev stuff - the other changes don't > touch x86 at all.) Right, at least my sparc patches really only deal with the Xsun server. I guess yours are similar. > BTW, There are two kinds of sparc64 support: usermode and kernel mode. > Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc > stuff on a 64-bit kernel. So Alpha patches don't help much there. > The biggest issue on the 32-bit sparc is unaligned memory accesses. Hmm, the alpha patches clean up many unaligned accesses, and since the alignment requirements for the alpha are the same as for sparc (save 64bit alignment on 32bit sparcs) the alpha patches should fix this too. I've been planning to merge the patch sets (I do the alpha X packages too), just haven't gotten to it yet (and I was sort of waiting to see if the central CVS archive that was suggested was going to happen). Maybe this is a good time... > I don't really want to step on any feet here, but it would be nice if > we could get the X source for Sparc into slink - and get the > UltraSparc support in there. (Eric plans on making the install work, > so X support would be an added bonus.) > > Nontheless, the current sparc binaries are a built by Anders from a > seperate tree. (Anders - my tree was made by merging the latest > UltraPenguin patches - a superset of the Red Hat patches - into > Branden's tree.) I would want some other sparc people to double check > my packages, before we actually include binary packages from my code > into slink. Can you send me your patches? I suspect that a lot of them are the same (and they aren't really mine, Mike Shuey did most of the original work on them), since they too are based on Red Hat's. That way I can merge them (or I could send you mine and let you do the merging, either is fine by me). Mainly what I want to achieve is that we don't change the way Xsun work (i.e. where it finds screens and such. It has been changing a bit, and I think I have a good method now). > If Anders has a tree that matches Branden's recent trees, I'll defer > to him (but ask that either he or I merge in the Mach64 and Creator > patches), otherwise, I'd like to the goahead from Anders et al to use > my stuff in slink (after appropriate testing). My sparc tree is currently too out-of-date to really be considered matching Branden's tree. My only concern with switching entirely is that we may loose fixes that are in my tree but not in yours, thus I'd rather try and merge our patches. > It shouldn't matter > too much (as long as the binaries work), since I believe Anders is > planning on starting from scratch on the 3.3.3.x releases. That's the idea, yes, since much of the code should be in 3.3.3.x already. > (I'm 99% sure the binaries work, the only issues would be install > script &c, and they are mostly copied from the current binary > packages. Also, I have to add a hard-coded XF86Config to the Sparc > Mach64 package - because XF86Setup doesn't work yet on the sparc > machines.) What problems does XF86Setup have on the ultras? I plan on fixing it to work on the alpha (where the problem mainly consists of non-existance of xserver-vga16, xserver-mono works, though probably not on TGA). Regards, /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student | Hem: +46 31 47 69 27 Chalmers University of Technology, G|teborg, Sweden | Mob: +46 707 27 86 87
Re: MDA's was: Yet another Linux distribution! :-)
>'From Bill Leach <[EMAIL PROTECTED]>' > >I will take a look at sendmail because of Manoj's remarks since the only >significant disadvantage to sendmail that I could see is that it can be a >real tough one to set up properly (if you are a continuously connected >mail server then it is almost a 'snap' to set up using the conventional >sendmail configuration). I don't see why it shouldn't be possible to make configuration just as easy for a dial-up case. We need to figure out what the typical dial-up cases look like and integrate them into the configuration as well. >I don't consider myself to be stupid but the e-mail issue is really >raising doubts... > >It should not require days of study of various documents, man pages, >HOWTOs, example configuration files, etc. just to get an email system >that: > >1) Places a vaild (to the ISP) From header on all internet bound mail >(no matter what the user's local network name might be). > >2) Send all 'outbound' mail to a smarthost depending upon which ISP >is in use. > >I realize that #1 is not really the MTA's 'responsibility' but it is the >logical place for this to be accomplished since any place else in the >'chain' is not unique (ie: there are too many mail composing software >packages, most (AFAIK) won't let you muck with the headers (and really >shouldn't). > >#2 IS the responsibility of the MTA but AFAIK none were designed with the >idea that you might have different 'smarthosts' as different times. #1 is simple to do, though it probably needs a few variants, depeding on whether the machine serves an entire domain or just a sigle account/email address. #2 Might be doable using sendmail's smarthost "MX" feature (setting the smarthost to a list of colon-separated hosts). With a bit of hacking it shouldn't be hard to have it read it from a file on each delivery attempt. Regards, /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | Mud at Kingdoms| [EMAIL PROTECTED] NetGuide Scandinavia | telnet kingdoms.se 1812| Fax: +46 31 50 79 39 http://www.netg.se | | Tel: +46 31 50 79 40 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intent to package: coda (+ copyright question)
> I think it's clear the intent is to say that CMU is legally distributing AFS. > the terms under which CMU is distributing it are as stated above and are DFSG > compliant. I think that's all we're concerned with: the terms under which our > users can use, modify, and distribute the software. > > So IBM owns the copyright, they gave CMU the right to distribute their code > under the above terms, and we received the software under those terms from > CMU. OK, that's what I thought they were trying to say as well, though it didn't appear clear to me. I guess I can put it into main then. > Actually the situation is a little more convoluted than that. AFS was > originally developped at CMU. Some students started a comany to develop and > market it, to which CMU gave the rights to AFS with the proviso that CMU have > the rights mentioned above. Later IBM bought this company, so we end up with > the above strange situation. Oh, I know quite a bit about AFS and DFS. Even had a guy from Transarc try to sell it to me at my previous job. Hopefully Coda can become all that AFS never managed (yes, I'm probably dreaming...) Regards, /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | Mud at Kingdoms| [EMAIL PROTECTED] NetGuide Scandinavia | telnet kingdoms.se 1812| Fax: +46 31 50 79 39 http://www.netg.se | | Tel: +46 31 50 79 40 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
intent to package: coda (+ copyright question)
I'm looking into packaging CMU's coda distributed filesystem. It is based on
AFS, with enhancements to allow disconnected use. There are kernel drivers for
it in the 2.1.x series and they are available as patches for the 2.0.x series.
Seeing that there are other kernel module packages available for the
distributed 2.0.x kernel, would it be useful to package up a kernel-module of
coda for 2.0? (I'll probably look in to that as well... Though I tend to be on
the bleeding edge myself.)
Now, on to the copyright question. The following is an excerpt from one file
(coda-src/vice/srvproc.cc to be exact). The CMU licence does not seem to pose
a problem, but the IBM notice is rather unclear. The only thing that is
obvious is that CMU can distribute the source. It would also appear that
derrived works are allowed. Thoughts please...
Regards,
/Anders
--->8---
/*
Coda: an Experimental Distributed File System
Release 4.0
Copyright (c) 1987-1996 Carnegie Mellon University
All Rights Reserved
Permission to use, copy, modify and distribute this software and its
documentation is hereby granted, provided that both the copyright
notice and this permission notice appear in all copies of the
software, derivative works or modified versions, and any portions
thereof, and that both notices appear in supporting documentation, and
that credit is given to Carnegie Mellon University in all documents
and publicity pertaining to direct or indirect use of this code or its
derivatives.
CODA IS AN EXPERIMENTAL SOFTWARE SYSTEM AND IS KNOWN TO HAVE BUGS,
SOME OF WHICH MAY HAVE SERIOUS CONSEQUENCES. CARNEGIE MELLON ALLOWS
FREE USE OF THIS SOFTWARE IN ITS "AS IS" CONDITION. CARNEGIE MELLON
DISCLAIMS ANY LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER
RESULTING DIRECTLY OR INDIRECTLY FROM THE USE OF THIS SOFTWARE OR OF
ANY DERIVATIVE WORK.
Carnegie Mellon encourages users of this software to return any
improvements or extensions that they make, and to grant Carnegie
Mellon the rights to redistribute these changes without encumbrance.
*/
static char *rcsid = "$Header: /afs/cs/project/coda-src/cvs/coda/coda-src/vice/
s
rvproc.cc,v 4.10 1998/01/12 23:35:42 braam Exp $";
#endif /*_BLURB_*/
/*
IBM COPYRIGHT NOTICE
Copyright (C) 1986
International Business Machines Corporation
All Rights Reserved
This file contains some code identical to or derived from the 1986
version of the Andrew File System ("AFS"), which is owned by the IBM
Corporation.This code is provded "AS IS" and IBM does not warrant
that it is free of infringement of any intellectual rights of any
third party.IBM disclaims liability of any kind for any damages
whatsoever resulting directly or indirectly from use of this software
or of any derivative work. Carnegie Mellon University has obtained
permission to distribute this code, which is based on Version 2 of AFS
and does not contain the features and enhancements that are part of
Version 3 of AFS. Version 3 of AFS is commercially available and
supported by Transarc Corporation, Pittsburgh, PA.
*/
--->8---
--
-- This message specially handmade by the imps of the Couterweight Continent
Anders Hammarquist, Mandolingatan 5, S-421 40 Västra Frölunda
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
