Bug#269329: Open-Xchange
Hi! Is there anything resembling a package for open-xchange? I have no interest in the licensing issues, and would be happy with a package that has sharp edges. -- Wesley W. Terpstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#268868: O: mico -- A fully compliant CORBA implementation
Package: wnpp Severity: normal I intend to orphan the mico package. The package description is: The acronym MICO expands to MICO Is CORBA. The intention of this project is to provide a freely available and fully compliant implementation of the CORBA standard. MICO has become quite popular as an open source project and is widely used for different purposes. As a major milestone, MICO has been branded as CORBA compliant by the OpenGroup. I have not used mico in over a year. I don't feel competent anymore to maintain it as I hardly remember how to even compile it. I think it would be better if someone who had more commitment to this package was looking after it as it requires some work. On the other hand, upstream has not made a new release forever. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=C, LC_CTYPE=C
Bug#237716: Whats the status?
On Wed, Jun 09, 2004 at 11:42:20PM -0300, Micah Anderson wrote: > Last I heard Wesley was going to wait a "week or so" before deciding > that the ITP has expired and you'd package this yourself. That was > Wed, 5 May 2004 21:25:13 +0200 ... I'm quite curious to know whats > going on with this? There is a package waiting in NEW on the debian servers. > While I do not want to discourage your grand plans Wesley, it seems > like it would be rather trivial to simply package the cryptsetup > binary instead of going through changing a lot of things? Simply packaging cryptsetup would have been pretty much useless. It is a tool for setting up block devices... If it doesn't work with your scripts for mounting filesystems, what good does it do you? > I personally would be thrilled to have them, but just getting the binary > out there would be nice too. (However, I should note that a perfectly > compatable cryptsetup is available in the hashalot package, but this is > based on the bash script, which I believe is being deprecated in favor of > the C program). Yes. The patch for mkinitrd is finished and I presume will be in the next upload of initrd-tools. However, Herbet Xu just resigned from Debian and it was with him that I was coordinating the patch. We'll see how it works out. At any rate, the package (with needed scripts) is in NEW waiting for the ftpmasters. The pathces are all ready, and it's pretty much taken care of now. -- Wesley W. Terpstra
Bug#237716: Cryptsetup + Debian
What is the status of this ITP? If no one else is going to do it, I would really like to do this. It seems to me that this package needs a lot of scripting glue to setup devices prior to mountall.sh. Also, it needs integration with mkinitrd for rootfs crypto. Furthermore, care has to be taken not to depend on libraries in /usr/lib. I have already talked to the dmsetup maintainer so that dmsetup is now in /sbin where it can be used in mounting /usr. I have most of the rest working on my own machines. If either of you is going to package this, I would like to help out so that these things are handled right. Otherwise, I would like to upload my own package. If I don't hear back in a week or so, I will assume that this ITP has timed out, and upload my own package... -- Wesley W. Terpstra <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#237716: cryptsetup.deb ITP
Are you still planning on uploading this to debian? If not, I would like to do so. If so, then I have several patches I'd like to give you... I have integrated cryptsetup into debian so that devices are setup just prior to mount via a crypttab. Furthermore, I've prepared integration with mkinitrd so that the root filesystem can be encrypted. Finally, I have a few scripts which allow using a simple XOR secret sharing scheme to allow booting via a half-key from usb stick, floppy disk, or cd. -- Wesley W. Terpstra
Bug#216035: Possibly adopt?
My girlfriend has a USB prism2 card for her laptop. She has been running 2.4.21 for some time, waiting for new wlan modules. I only realized today they were not coming b/c it was orphaned. It seems to me that 2.6 does not support her card. Can you confirm this? If so, then I plan to adopt this package. I don't know anything about hostap functionality though, and I am considering dropping this functionality. Would it be missed? Thanks. -- Wesley W. Terpstra <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#171314: uqm
On Fri, May 09, 2003 at 02:29:41PM -0400, Joey Hess wrote: > Ah, I was wondering what the holdup was on this package. > > Why don't you upload uqm sans voices and music for debian. Then set up > your own apt repository for the voice and music data. Or just the > voices, iirc the music is not very big by itself. Then anyone who wants > the voices can install a package from your apt repository, and those of > us who just want to play super melee, or who grew up with the dos > version with no voices, can get it right in debian. The upload I already made could be accepted sans voices and music. I uploaded the pieces as seperate source packages precisely to reduce bandwidth needs for the mirrors when only one component changes. So, if the ftpmasters accepted uqm and uqm-data, there would be no problem. -- Wesley W. Terpstra <[EMAIL PROTECTED]> pgpdPVavm2vLV.pgp Description: PGP signature
Bug#171314: uqm
On Fri, May 09, 2003 at 10:55:49AM -0400, Matt Zimmerman wrote: > Assuming that the game itself does not depend on the voice and music > packages (and it should not, as they are completely optional) this should > not prevent the core game from entering the archive, which should be about > 20M as you say. There is at least precedent for games of approximately that > size. The packages I made do not have this dependency. uqm-data and uqm are all that is required to play. This even includes the original sound track (good old .mod's). Only the special added music from the 3DO version is in uqm-music. --- Wes
Bug#171314: uqm
tags 171314 +pending On Fri, May 09, 2003 at 09:35:39AM -0400, Matt Zimmerman wrote: > On Fri, May 09, 2003 at 11:40:30AM +0200, Wesley W. Terpstra wrote: > > > On Thu, May 08, 2003 at 09:25:00PM -0400, Matt Zimmerman wrote: > > > Please close this WNPP bug when your packages are in the archive. > > > > I intend to; in fact the bug has a closes: line in the Changelog. > > I think the package has been on hold because the ftp-admins don't like how > > big it is. ;-) > > Yes, I see that now. I assumed you weren't aware of this bug because you > didn't retitle it, nor send a message to it indicating your intentions. > When you decide to package something for which there is an RFP filed, you > should retitle the bug to an ITP. There are instructions here: > > http://www.debian.org/devel/wnpp/ Indeed. I should have. I see you have already done so. At the time, I packaged it for myself. Then I saw the bug report and decided to upload my packages to close it. I expected it to go into the archive and close the bug immediately. However, this has turned out not to be the case. I'm sorry for the confusion it caused which led to you duplicating effort. I am doubtful that this package will ever land in the archive though as I have heard some second-hand disparaging comments about the size (300Mb) of the package from ftp-admins. Maybe it shouldn't be in debian; I'm not sure. At any rate, it has now been sitting in the queue for a month. I have been considering replacing the uqm-voice and uqm-music packages with a set of scripts which simply fetch the the datafiles from the upstream website and install them. This way it would be more palatable to the ftp-admins at a size of 20Mb. But, I would rather not since this would make debian's uqm vulnerable to breakage by upstream moving or changing the data. --- Wes
Bug#171314: uqm
On Thu, May 08, 2003 at 09:25:00PM -0400, Matt Zimmerman wrote: > Please close this WNPP bug when your packages are in the archive. I intend to; in fact the bug has a closes: line in the Changelog. I think the package has been on hold because the ftp-admins don't like how big it is. ;-) -- Wesley W. Terpstra <[EMAIL PROTECTED]>
Bug#174875: ppoeconf already does PPtP/dsl...?
I have a PPtP/DSL connection. pppoeconf already seems to work? T-Online and mediaways both worked with it just fine. What is the specific issue needing resolution? Since I use this package regularily I may be willing to adopt it. -- Wesley W. Terpstra <[EMAIL PROTECTED]> pgprgAhyQtJas.pgp Description: PGP signature
Bug#132387: ITP: st -- State Threads Library
Package: wnpp Severity: wishlist Upstream URL: <http://prdownloads.sourceforge.net/state-threads/st-1.3.tar.gz> Please note, st-1.3[a-z] are OLDER than st-1.3. 1.3 is the latest stable and unstable release. Upstream Authors: Gene Shekhtman <[EMAIL PROTECTED]> Mike Abbott<[EMAIL PROTECTED]> Packager: Wesley W. Terpstra <[EMAIL PROTECTED]> presently in the NM queue. Copyright: The State Threads library is a derivative of the Netscape Portable Runtime library (NSPR) and therefore is distributed under the Mozilla Public License (MPL) version 1.1 or the GNU General Public License (GPL) version 2 or later. What it is: The State Threads library has an interface similar to POSIX threads. However, the threads are actually all run in-process. This type of threading allows for controlled schedualing points. It is highly useful for designing robust and extremely scalable internet applications since there is no resource contention and locking is generally unnecessary. It can be combined with traditional threading or multiple process parallelism to take advantage of multiple processors. See: <http://state-threads.sourceforge.net/docs/st.html> for further information about how state threads improve performance. Note: This package will be sponsored by 'Ryan Murray' (neuro) <[EMAIL PROTECTED]> until such a time as I can dupload it myself. -- Wesley W. Terpstra <[EMAIL PROTECTED]> pgpfo2WdCLx9E.pgp Description: PGP signature
