Re: Bug#223781: [RFA]: usemod-wiki -- Perl-based Wiki clone
Hello Julian, On Sat, Dec 13, 2003 at 12:33:19AM +0100, Julian Mehnle wrote: > Alexander Wirt wrote: > > Am Fr, den 12.12.2003 schrieb Julian Mehnle um 15:32: > > > Benjamin Drieu wrote: > > > > I no longer use usemod-wiki and thus have no time to maintain it. > > > > Package is in good shape, no serious bugs. Very few work is needed > > > > to maintain it as release cycle is quite long. > > > > > > > > The only one todo item is to package version 1.0, which requires > > > > some changes to the wiki database. Peter Gervai <[EMAIL PROTECTED]> > > > > has already made a package for this and is going to NMU > > > > usemod-wiki. But as he does not have time to adopt it, we need a > > > > new maintainer. > > > > > > As I'm using UseMod Wiki on a slew of Debian machines, I'd be more > > > than willing to continue maintaining usemod-wiki, but I'm no Debian > > > Developer, so I'd need a sponsor until I decide and manage to become > > > one. > > > > I use it on some systems too, so I would be pleased to be your sponsor. > > Get in touch with me if you have packages ready for upload/inspection. > > Are you going to do an NMU wrt usemod-wiki 1.0? I would like to avoid to adopt another package if possible, so if you want to have it please be our guest. > If yes, are you going to > include an automatic upgrade mechanism for old singlebyte Wikis? If yes, > I'll wait for that NMU before starting my own packaging work. Well no. But what's funny is that I just installed 1.0, changed it to utf8, did what the readme told me and it worked... > Otherwise, would you mind sending me whatever you have packaged up for > 1.0, so I can add an automatic upgrade mechanism (which I'd really like to > include with the initial release of the 1.0 Debian package)? Of course I don't mind, feel free to use it! see: http://narya.grin.hu/cgi-bin/viewcvs.cgi/trunk/usemod-wiki/ if you wonder what did I change, or ftp://narya.grin.hu/pub/debian/ to get all the stuff. Best wishes, Peter
Bug#113653: ITP: links-lua-ssl -- a fork of links supporting lua language, resulting a programmable browser with hooks
Package: wnpp Version: 0.96; reported 2001-09-27 Severity: wishlist * Package name: links-lua-ssl Version : 0.96p11 Upstream Author : links-lua team * URL : http://sourceforge.net/projects/links/ * License : GPL Description : a fork of links supporting lua language, resulting a programmable browser with hooks the package will contain patches the upstream author did not want to include, including, but not limited to IPv6, the "dummy javascript" patch, and other smaller ones like http_proxy env support. i do not intend to package non-ssl version, either because there's already enough links exist in debian, or because everyone uses ssl version anyway. the package is available for texting at: ftp://yikes.tolna.net/pub/linux/release/debian/links-lua-ssl_0.96-0.0_i386.deb advices are welcome, please cc to personal email. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux Yikes 2.2.19 #1 Fri Apr 6 03:40:59 CEST 2001 i686 Locale: LANG=C, LC_CTYPE=hu_HU
Re: maybe ITP rsync mirror script for pools
On Wed, Jan 03, 2001 at 11:57:07PM +0100, Marco d'Itri wrote: > Please don't encourage private mirrors! > > I have been the administrator of ftp.it.debian.org since a long time, > and I notice there are many sites doing nightly mirrors for their own > use. I believe "their own use" is a bit too broad. I do a nightly mirror for example "for my own use", which means covering local MAN networks and even some farther, national users. Not everyone is able to wait for 10 times longer for apt-getting, when the "official" national mirror slow (or doesn't exist at all), and the international ones are slow as hell (because national bandwidth is much more bigger and cheaper for the providers). It would be, however, maybe nice to make a free-for-everyone unofficial mirror registration webpage, where people could register their mirror site, location, update rate, accessiblity, and many other properties. Maybe there is such page, I don't know. I'm sure many larger local networks mirror for the users: often it's cheaper than any other methods. If people would find a closer, faster mirror, maybe they'd stop mirroring for themselves. > They could save bandwidth and disk space just by using a correctly > configured squid cache. You mean a squid accepting 50MB+ files for caching? Memory isn't *THAT* cheap. I don't know how much memory would it use... (Bigger files mean bigger memory hotlist plus bigger disk space requirements which means even bigger memory footprint.) I don't think this is a good idea, but the mileages tend to spend their valuable times with varying, cough, cough. cya, grin
