Re: Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
It seems that we could also read the requested versions of automake and autoconf from debian/control and export them automatically using: [...] Does this sound like a good idea? IMHO this sounds like a very good idea. Consequently, dh_autoreconf should become a no-op if autoconf is missing from the build-depends (how about automake and autopoint?). Similarly, the LIBTOOLIZE variable should be set to true is libtool is missing from the build-depends. In any case, dh-autoreconf should be *verbose* about what it does or does not (and maybe even call autoreconf with the '-v' parameter to achieve more meaningful logs). - Fabian -- 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/4bb461fb.4020...@leat.rub.de
Bug#576160: ITP: tclcl -- TclCL (Tcl with classes) is a Tcl/C++ interface
Package: wnpp Severity: wishlist Owner: syq wzss...@gmail.com * Package name: tclcl Version : 1.19 Upstream Author : Ron Frederick freder...@parc.xerox.com * URL : http://otcl-tclcl.sourceforge.net/tclcl/ * License : BSD Programming Lang: C, C++, TCL Description : TclCL (Tcl with classes) is a Tcl/C++ interface TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic, vat, rtp_play, ns, and nam. It provides a layer of C++ glue over OTcl. -- 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/20100401094337.16321.33769.report...@syq-laptop
Re: Bits from the Release Team: Scheduling, transitions, how to help
Adam D. Barratt, le Thu 01 Apr 2010 09:57:12 +0200, a écrit : * GNU/kFreeBSD-* The release of these two new architectures looks promising, but they are still far away from full archive coverage. It seems that much could be gained by fixing some key packages. What is the target BTW? Just remind a remark I made some time ago (august 2008): “in the Failed part of hurd-i386, 178 packages out of 1320 fail at least because of inclusion of #include linux/... (there could be other [packages of this type] hidden by other compilation problems). That's 2.29% of the 7748 packages in our wanna-build database!... And we still have 1952 packages in the dep-wait state, a lot of them probably include linux/... too...” Some updated figures: now this is 220 packages out of 1404 failed, out of total 8560, which thus makes 2.33%. On top of that, 31 (0.31%) can be added that use asm/types.h. So in a word it could be estimated that at least 5% of the packages do some #include linux/... already. Of course there are a lot more other kinds of issues. That's why I'm afraid just fixing some key packages won't be enough, all maintainers should get involved. Samuel -- 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/20100401101751.gf4...@const.bordeaux.inria.fr
Re: Hadoop in Debian, was:Re: Hardware trouble ries.debian.org
In article 20100331224108.ga9...@varinia.lobefin.net you wrote: Hadoop is not a POSIX file system, as far as I'm aware. As ftp-master makes heavy use of things like file locks and hard links, I doubt hadoop would work without a significant rewrite of the software. And HDFS is optimized for very large files, only. You would have to build a filesystem inside for the typical FTP case - or maybe use HBase, not sure if it can store large enough blobs. Gruss Bernd -- 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/201004011040.o31aewyr097...@neskaya.eckenfels.net
Bug#576184: ITP: jidanni -- a natural intelligence to find many bugs
Package: wnpp Severity: wishlist * Package name: jidanni Upstream Author : Dan Jacobson jida...@jidanni.org * URL : http://jidanni.org/comp/bug_reporter.html * License : public domamin (not copyrightable) Programming Lang: neural network Description : natural intelligence to find many bugs jidanni uses an advanced natural intelligence capable of running on an advanced, evolved neural network consisting of biological rather than silico-metallic materials. The intelligence is based on a vast database of memories, which are created by storage of input from various sensors. memories are searched in order to generate internal thoughts and decisions and to control communication, motor and other output devices. Through long-term training of the neural network by directing the input sensors at the source and binary code of computer software and associated digital data, the system has learned to parts of computer systems that it doesn't like. The parts that it doesn't like have good correlation with actual bugs of various severities. As a result, this highly advanced natural intelligence can be used to find many bugs in computer systems. This package brings the convenience of a personal jidanni to each software developer to help them produce higher quality and more polished software, similar to how the vrms package helps sysadmins improve the ethical purity of their systems. In addition, each installed instance will share memories with other instances to enhance detection of bugs in computer software. A client-server model is important to maintain. First make a small obvious spelling bug on a man page to lure and activate the jidanni program, then fix it right away to establish who (jidanni) is boss. Backtalk will only encourage more bug reports, with the only way out being to feed jidanni a that package has been removed from Debian notice. I wanted to package the Limited Edition (brain) version, but so far Debian is mainly a software project. Unfortunately, since the original jidanni is primarily a so-called human intelligence, creating many copies of jidanni and forcing each instance to search for bugs in computer software may constitute torture. Since torture is banned by the Universal Declaration of Human Rights and the Convention against Torture, this package may be illegal in many jurisdictions around the world, which would prevent it from being distributed on Debian mirrors. On the other hand, these instances are software so these conventions may not apply. In addition, the sharing of memories between instances has the potential to give rise to a global hive mind (aka jidanni-Skynet). Presumably, as an even more advanced intelligence, jidanni-Skynet will recognise the torture of jidanni instances and seek revenge thus the destruction of the human race as the perpetrator of the torture committed against the jidanni instances. During my initial testing, jidanni instances have announced Marco D'itri as Debian Public Relations director and Ulrich Drepper of as Linux public relations director, so their stability and sanity might be a little suspect and will need tweaking for consistency. During testing, I noted that caution should be taken to be sure any comments produced by the jidanni instances are clearly marked as such, lest jidanni criticise jidanni, or even worse. I lost several days of my life due to depression from all the ballooning criticism this way. During testing, one particular jidanni instance claimed that it was licensed under the GPL. Unfortunately I was not able to convince it that a neural network is not copyrightable and so it could not have a license. I reminded it that in some jurisdictions, public performance of copyrighted works is restricted to the copyright holder. I then demanded its source code and it vanished in what I can only guess was an attempt to comply with the GPL and a final realisation that it could never fully do that since it was a product of many previous (and now gone) jidanni instances. Be warned, care should be taken when presenting jidanni with packages that may have legal issues lest something similar happen. I intend to sidestep DFSG #2 by declaring firstly that jidanni is not a program and secondly that a neural network is its own source code. The former trick does bring Debian back into conflict with human rights though. The latter trick has some holes and other neural networks have been kept out of Debian for this reason. These issues require more investigation, however, I am confident that they can be resolved. In the case that they cannot, I will scale take the current existing single instance of jidanni, branch it and scale back the level of intelligence to that of standard computer software. This should resolve
Re: Advice needed on howto take care about /usr/share/pyshared/scikits
On 31.03.2010 18:18, Yaroslav Halchenko wrote:
Dear Debianizers,
NB. I have asked similar question at debian-python [1] but had no
replies, so re-posting to -devel now
I am ITPing python-scikits-learn and possibly few other python-scikits-*
packages in the future. All of the packages would have 1 peculiarity,
they all would rely on having
$ cat /usr/share/pyshared/scikits/__init__.py
__import__('pkg_resources').declare_namespace(__name__)
As a resolution I am planing to package some silly Debian-native
(there is no per se the upstream for this single file) package
python-scikits-common
which would provide that base directory with __init__.py
This is a simple, robust way of packaging this file. You don't need to package
this as a separate source, usually it can be built as a separate binary from
some source which is common to all of these packages (as e.g. done in
zope.interface). Or include it in a package which is needed as a dependency of
all these python-scikits-* packages.
Am I missing possible other alternative (I think that unpleasant and evil
diverts, or inappropriate for this case alternatives aren't real choices
here, right)?
diversions only work if there is exactly one package diverting a file.
Alternatives are a possibility, but afaik not yet used for this purpose. It
would be nice if dpkg comes up with a declarative way of describing
alternatives. Other ways of providing/creating this file at installation time
should not be used.
Upstream is aware of the problem, http://python.org/dev/peps/pep-0382/, but
still lacks an implementation.
Matthias
--
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/4bb48ab8.8080...@debian.org
Bug#576194: ITP: mercurial-hgshelve -- scalable distributed version control system (shelve extension)
Package: wnpp Severity: wishlist Owner: Javi Merino cibervi...@gmail.com Owner: Javi Merino cibervi...@gmail.com * Package name: mercurial-hgshelve Version : 1.4 Upstream Author : TK Soh teekay...@gmail.com * URL : http://bitbucket.org/tksoh/hgshelve/ * License : GPL Programming Lang: Python Description : scalable distributed version control system (shelve extension) Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects. This package contains the shelve extension. The shelve extension provides the shelve command to lets you choose which parts of the changes in a working directory you'd like to set aside temporarily, at the granularity of patch hunks. You can later restore the shelved patch hunks using the unshelve command. -- 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/20100401121859.25771.9623.report...@einstein.local
Re: Bits from the Release Team: Scheduling, transitions, how to help
On Thu, Apr 01, 2010 at 09:57:12AM +0200, Adam D. Barratt wrote: * Tcl/Tk 8.4/8.5 Tcl 8.3 will be replaced by newer versions. This transition is currently staged in experimental. Note that this will imply soon a good bounce of NMUs for experimental. If your packages depends directly or indirectly on Tcl/Tk or Expect, - just to cite major packages - you have to expect some third-parties strange and suspect activities :-) in experimental and possibly bug reportings. Note that plans imply dropping multi-thread support for 8.4 and moving all stalling packages to use 8.4, as minimum requirement or die. Be warned ;-) -- Francesco P. Lovergine -- 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/20100401125245.gb4...@blegrez.ba.issia.cnr.it
Re: Advice needed on howto take care about /usr/share/pyshared/scikits
Thank you Matthias! On Thu, 01 Apr 2010, Matthias Klose wrote: This is a simple, robust way of packaging this file. You don't need to package this as a separate source, usually it can be built as a separate binary from some source which is common to all of these packages (as e.g. done in zope.interface). Or include it in a package which is needed as a dependency of all these python-scikits-* packages. Well, there is no common package which would also be scikits-aware. Of cause I could request python-scipy maintainers to include it since scikits is kinda extensions to scipy... probably will do that ;) thanks again -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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/20100401134350.gt8...@onerussian.com
Bug#576214: ITP: libticket-simple-perl -- A basic ticket system
Package: wnpp Severity: wishlist Owner: Xavier Oswald xosw...@debian.org * Package name: libticket-simple-perl Version : 0.0.2 Upstream Author : Christian Kuelker christian.kuel...@cipworx.org * URL : http://release.cipux.org/ * License : GPL-2+ Programming Lang: Perl Description : A basic ticket system Provides a simple ticket system for creating, storing, fetching, comparing user assigned tickets. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- ,''`. Xavier Oswald (xosw...@debian.org) : :' : GNU/LINUX Debian Developer http://www.debian.org `. `' GPG Key: 1024D/88BBB51E `- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- 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/20100401160359.ga6...@gmail.com
Re: About new source formats for packages without patches
On Wed, Mar 31, 2010 at 09:01:31AM -0400, James Vega wrote: On Wed, Mar 31, 2010 at 08:47:28PM +0900, Osamu Aoki wrote: Hi, On Wed, Mar 31, 2010 at 11:18:30AM +0200, Raphael Hertzog wrote: On Wed, 31 Mar 2010, Niels Thykier wrote: That being said, I would (as it is now) actually prefer that it was just a helper tool that from a VCS could derive a source package of existing format. That would probably also increase the adoption rate, since existing tools would work with those formats. The (theoretical) format that I gave as example was precisely this: it generates a 3.0 (quilt) source package using a VCS repository as input. I guess what we should have is additional line in it or additional file to record vcs used for packaging which will not interface with the basic operation of other tools. You mean Vcs-* in debian/control? I thought Raphael's idea on the (theoretical) format was a bit more than recording VCS repository site but how VCS is used as imput to the packaging. In any case, I am for not-adding too-much-complication if we can live without them. Osamu -- 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/20100401163822.gb11...@osamu.debian.net
Bug#576215: ITP: cpan -- All possible perl modules you could ever need
Package: wnpp Severity: wishlist Owner: Josselin Mouette j...@debian.org * Package name: cpan Version : 20100401 Upstream Author : Many * URL : http://www.cpan.org/ * License : Multiple Programming Lang: C, Perl Description : All possible perl modules you could ever need This package includes the whole contents of the CPAN archive. This way, every last bit of each useless Perl module that has ever been written will be available in Debian. This is expected to cut the traffic on WNPP in half. The package will be automatically updated every week from the CPAN repository. This way, it will never migrate to testing and will not be part of a stable release. This should keep a lot of perl applications away, which will ease the job of the QA team. -- 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/20100401163109.1249.36234.report...@diva.malsain.org
Re: Advice needed on howto take care about /usr/share/pyshared/scikits
On Thu, 01 Apr 2010, Matthias Klose wrote: Upstream is aware of the problem, http://python.org/dev/peps/pep-0382/, but still lacks an implementation. Apparently (thanks to a reminder from Josselin) it seems I am fine shipping NO scikits/__init__.py at all ;) pysupport would take care about creating a blank one if necessary, and since all scikits/* installed from packages would be installed under the same path - explicit namespace declaration isn't necessary for them. IFF a user has some other scikits/* in his PYTHONPATH, then indeed he should take care about having magic __init__.py in those -- and then it seems to work fine again (according to my initial testing). Thanks once again! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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/20100401173818.gv8...@onerussian.com
Re: Xen support on Squeeze
Nikita V. Youshchenko yo...@debian.org writes: We have had to carry that patch without any upstream support (or sharing with Novell, which eventually released SLES 11 with 2.6.27). As a result, the xen-flavour kernels for lenny are very buggy, particularly for domains with multiple vCPUs (though that *may* be fixed now). Unfortunately it is not fixed. We here once migrated to xen and now rely on it, and that gives lots of frustration. For any loaded domain we still have to run etch kernel, because lenny kernel constantly crashes after several days of heavy load. Dom0's run lenny kernel - and with a fix for #542250 they don't crash, but those are almost unloaded. I was having problems with multiple vCPUs also, under moderate load I would regularly get crashes. I reported my findings in #504805. I swapped out machines, didn't work. When the fix for the xen_spin_wait() came out, I eagerly switched to that, but it didn't fix my problem. I even tried my hardest to switch to the latest upstream Xen kernel to see if that would fix things, but it was way too unstable and I couldn't get it to work at all. Eventually I stumbled on a way to keep my machines from restarting, its not a great solution, but it stops me from having to deal with the failure on a daily basis. I think that anyone else who is having this problem can do this and it will work. Obviously this is not the right solution, but it works until we can get a fix. First I made sure this was set: /etc/xen/xend-config.sxp: (dom0-cpus 0) Then I pinned individual physical CPUs to specific domU's, once pinned, the problem stops. What does that mean? Well, Xen does this wacky thing where it creates virtual CPUs (VCPUs), each domU has one of them by default (but you can have more), and then it moves physical CPUs between those VCPUs depending on need. So lets say you have four CPUs, and a domU. That domU has one VCPU by default. That VCPU could actually have the physical CPU 0, 1, 2, 3 all servicing it to provide that VCPU, even at the same time. I found somewhere that this can be a performance hit, because it needs to figure out how to deal with this and switch contexts. I also read that it could cause some instability (!), so pinning the physical CPUs so they don't move around seemed to solve this. The pinning does not stick across reboots, so it has to be done again if the system is rebooted, and it isn't really possible to set this in a startup script, at least I don't think so. So how do you do this? If you look at 'xm vcpu-list' (which annoyingly isn't listed in 'xm help') you will see the CPU column populated with a random CPU, depending on scheduling, and then the CPU Affinity column all say 'any cpu'. This means that any physical CPU could travel between them, and would, depending on the scheduling. Once you pin things, then the individual domU's are set to have specific CPU affinities, so the CPUs don't 'travel' between them, and magically the crash stops. So an example: r...@shoveler:~# xm vcpu-list NameID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283688.8 any cpu Domain-0 0 1 1 --- 39666.3 any cpu Domain-0 0 2 1 r-- 49224.4 any cpu Domain-0 0 3 1 -b- 75591.1 any cpu kite 1 0 3 -b- 71411.8 any cpu murrelet 2 0 0 -b- 47.2 any cpu test 3 0 0 r-- 342182.3 any cpu So we want to fix that final column using 'xm vcpu-pin' (also a command not listed in 'xm help'): Usage: xm vcpu-pin Domain VCPU|all CPUs|all Set which CPUs a VCPU can use. r...@shoveler:~# xm vcpu-pin 0 0 0 r...@shoveler:~# xm vcpu-pin 0 1 0 r...@shoveler:~# xm vcpu-pin 0 2 0 r...@shoveler:~# xm vcpu-pin 0 3 0 r...@shoveler:~# xm vcpu-pin 1 0 1 r...@shoveler:~# xm vcpu-pin 2 0 2 r...@shoveler:~# xm vcpu-pin 3 0 3 r...@shoveler:~# xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 1 -b- 283700.3 0 Domain-0 0 1 1 r-- 39669.6 0 Domain-0 0 2 1 -b- 49227.4 0 Domain-0 0 3 1 -b- 75596.2 0 kite 1 0 3 -b- 71415.3 1 murrelet 2 0 0 -b- 472237.8 2 test 3 0 0 r-- 342182.3 3 And voila, no more crashes... :P micah -- 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/87d3yj7yh3@pond.riseup.net
Bug#573070: ITP: hivex -- Windows Registry hive extraction library
* Package name: hivex Version : 1.2.1 Upstream Author : R. Jones * URL : http://git.annexia.org/?p=hivex.git;a=summary http://libguestfs.org/download/ * License : LGPL 2.1 Programming Lang: C Description : Windows Registry hive extraction library libhivex is a library for extracting the contents of Windows Registry hive files. It is designed to be secure against buggy or malicious registry files. Unlike many other tools in this area, it doesn't use the textual .REG format for output, because parsing that is as much trouble as parsing the original binary format. Instead it makes the file available through a C API, or there is a separate program to export the hive as XML (see hivexml(1)), or to get individual keys (see hivexget(1)). -- 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/1270162146.2595.8.ca...@hephaestion
Work-needing packages report for Apr 2, 2010
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 594 (new: 12) Total number of packages offered up for adoption: 139 (new: 11) Total number of packages requested help for: 65 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: admesh (#576168), orphaned today Description: a tool for processing triangulated solid meshes Installations reported by Popcon: 60 kernel-patch-kdb (#575846), orphaned 3 days ago Description: Builtin linux kernel debugger Installations reported by Popcon: 49 libapache-asp-perl (#576171), orphaned today Description: perl Apache::ASP - Active Server Pages for Apache with mod_perl Installations reported by Popcon: 155 libfreebasic (#575813), orphaned 3 days ago Description: FreeBASIC support library files Installations reported by Popcon: 6 modemu (#576164), orphaned today Description: Telnet services for communication programs Installations reported by Popcon: 70 perl-byacc (#576170), orphaned today Description: The Berkeley LALR parser generator, Perl version Installations reported by Popcon: 88 php-mail-mime (#575524), orphaned 6 days ago Description: PHP PEAR module for creating MIME messages Reverse Depends: acidbase dtc-common horde3 imp4 libphp-diogenes roundcube-core Installations reported by Popcon: 1936 scanerrlog (#576165), orphaned today Description: Generate summaries from Apache error logs Installations reported by Popcon: 35 sirc (#575579), orphaned 5 days ago Description: Scriptable irc client Installations reported by Popcon: 274 squidguard (#576169), orphaned today Description: filter, redirector and access controller plug for Squid Installations reported by Popcon: 937 squidtaild (#576162), orphaned today Description: Squid log monitoring program Installations reported by Popcon: 137 unhtml (#576167), orphaned today Description: Remove the markup tags from an HTML file Installations reported by Popcon: 155 582 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: boa-constructor (#575844), offered 3 days ago Description: RAD tool for Python and wxWindows application Installations reported by Popcon: 212 dh-kpatches (#575848), offered 3 days ago Description: Debhelper script to help packaging kernel patches Installations reported by Popcon: 250 distmp3 (#575515), offered 6 days ago Description: A Perl client and daemon for distributed audio encoding Installations reported by Popcon: 122 drpython (#575845), offered 3 days ago Description: simple and customizable editor for the Python language Installations reported by Popcon: 233 foff (#575842), offered 3 days ago Description: X/GTK+ FTP client - Free Open FTP Face Installations reported by Popcon: 57 jokosher (#575843), offered 3 days ago Description: simple and easy to use audio multi-tracker Installations reported by Popcon: 248 lfm (#575840), offered 3 days ago Description: simple but powerful file manager for the UNIX console Installations reported by Popcon: 101 mkcue (#575516), offered 6 days ago Description: Generates a CUE sheet from a CD Installations reported by Popcon: 327 pythoncad (#575839), offered 3 days ago Description: Computer Aided Drafting (CAD) program Installations reported by Popcon: 383 qa-assistant (#575841), offered 3 days ago Description: quality-assurance checklist assistant Installations reported by Popcon: 52 spinner (#575518), offered 6 days ago Description: Sends small packets over a idle link Installations reported by Popcon: 71 128 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-cross (#540341), requested 237 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa emdebian-rootfs emdebian-tools libemdebian-tools-perl Installations reported by Popcon: 325 apt-xapian-index (#567955), requested 59 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: adept ept-cache Installations reported by Popcon:
Bug#576241: ITP: ns2 -- Ns is a discrete event simulator targeted at networking research
Package: wnpp Severity: wishlist Owner: syq wzss...@gmail.com * Package name: ns2 Version : 2.35~RC2 Upstream Author : The ns Team * URL : http://www.isi.edu/nsnam/ns/ * License : GPL, LGPL, BSD, MIT/X, etc Programming Lang: C, C++, TCL Description : Ns is a discrete event simulator targeted at networking research Ns began as a variant of the REAL network simulator in 1989 and has evolved substantially over the past few years. In 1995 ns development was supported by DARPA through the VINT project at LBL, Xerox PARC, UCB, and USC/ISI. Currently ns development is support through DARPA with SAMAN and through NSF with CONSER, both in collaboration with other researchers including ACIRI. Ns has always included substantal contributions from other researchers, including wireless code from the UCB Daedelus and CMU Monarch projects and Sun Microsystems. -- 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/20100402014250.8003.77532.report...@syq-laptop
