Hi, for the reasons I've outlined on -private, I'd like to give away my packages: apache2-redirtoservname This package comes with upstream duties as well, since I wrote it. It is unlikely that for the actual functionality bits you'll ever need to do more than trigger a rebuild, but the package is severely lacking documentation. It is in use by a few sites, so I wouldn't like to see it gone. asio This is a header-only C++ library which has also been accepted into Boost some time ago, but remained around as a standalone version as some programs still use the "old" names outside the Boost namespace. It may be worth investigating (together with upstream) whether this package can be replaced by something that pulls in Boost.Asio. Other than that, the package is fairly low-maintenance, but you will require strong C++ skills. asterisk-prompt-it asterisk-prompt-se I've packaged these ages ago, and they are horribly outdated. The packages aren't overly complicated, as they just contain a tree of data files (so they are ideal for a beginner), but since they are artistic works, adressing bugs is bound to be difficult as you are essentially dependent on upstream. ctapi This is a tricky one, and you need experience with smartcards. The package exists only because that API is so old and "simple" that everyone has their own implementation now, which leads to file conflicts. This package is supposed to be the common definition, which means that as maintainer, you'll need to coordinate with the maintainers of other packages that have conflicting definitions. iptables-persistent Again, a very small package that does just one thing, load firewall rules at startup. Since some systems rely on this package for security, you should know what you are doing, and there are a few open wishlist bugs that need to be addressed. libopenusb This is a fairly straightforward library+plugin package with a difficult upstream bug and a mostly inactive corporate upstream. Also, porting is required for FreeBSD support, so it might be a good idea for someone using FreeBSD to pick this up. misdn-kernel misdn-user Both of these are fairly outdated, as the software wasn't ready for real world use outside of tightly controlled environments (i.e. embedded systems) back then, and getting it to work without it falling over on every upgrade is going to be hard. Upstream is fairly responsive, but the package still hasn't stabilized to the point where I'd give it to end users. Most of the kernel drivers are in the mainline kernel now, although the version in upstream's git repository are often newer and have a different ABI -- so expect stuff to break fairly often. python-imaging-doc-handbook It would be nice to have a newer version of this package, but AFAIK the newer versions of the handbook have a different licence that makes this difficult. The package is less of a technical than a legal challenge. redshift An interesting gadget, fairly new, but stable. Some python knowledge would be beneficial for the Gtk bits, otherwise, only basic packaging knowledge required and ideal for a beginner. towitoko This is related to chipcards again, and is one of the candidates to use the common "ctapi-dev" package; this should happen in your first upload as the versioned Replaces: in ctapi-dev will only work against the current version of the package. Also, there are some l10n patches outstanding, which are blocked by the ctapi "transition". uclibc This is a very tricky one, and is probably best with the emdebian project. On the regular Debian architectures, only a single arch:all binary package containing a copy of the source package is built, but on several "uclibc-linux-<cpu>" architectures, we build (or at least try to) several library packages. As these architectures aren't fully bootstrapped yet, the package will need to crosscompile cleanly, and lots of people will have different use cases requiring different configurations, which should then be distinguished via the "DEB_VENDOR" variable. I'm still going to be available to answer questions about any of those packages as I know them fairly well, but I'd like to drop the responsibility for maintaining them soon. Proper RFA/O bugs will be forthcoming for all packages not taken over in a week. Simon
Attachment:
signature.asc
Description: Digital signature