Re: cdrtools
Hello, [ I'm leaning somewhat out of the window here w/o being a law expert ] On Wed, 12.07.2006 at 12:46:51 -0700, Erast Benson <[EMAIL PROTECTED]> wrote: > Joerg clearly stands that: > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may > be called "scripts": > ... > Makefiles are programs written in a non-scripting language: > I call this language "make". It is a non-algorithmic language but but he and you are dead wrong on that, imho. For me at least, a "script" is anything that can be executed using shebang, and makefiles _can_, as your famous debian/rules file demonstrates. > This means in other words: If I take other people's GPL code and create > a "derived work" from that code, I need to make the whole work available > under GPL. I do not need to make non-GPL code available at all, if GPL > code is derived on that code. I do not need to make the build system > available under GPL (GPL §3 requires me to make it available but does > not mention a license) and the build system is not code that is > "derived" from the GPLd project.""" This is imho a very broken interpretation because the build system is usually an intimate part of the whole, and often enough, source code with no idea about how to tie everything together is not nearly half as useful as a "full" source is. Think of KDE w/o a build system, or the Linux kernel, for instance... which would almost certainly defeat the purpose of enabling others to change and expand on "given" code, and also open the door for all kinds of abuse. Maybe we should solicit the legal opinion of the FSFE or so on this matter. But in reality, this all belongs on [EMAIL PROTECTED] Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > > The specific example used was some spam source sitting in the same /27 > > netblock in a colo server room, and getting through the graylister because > > a proper MTA from the same /27 netblock had already been added to the > > "approve it, it does retries" list of the graylister. > > Ok, now I understand. As I've already said, graylisting on /27 > netblocks amounts to inventing new network standards, which I believe > should go through the IETF standardization process before we block > email from people who don't comply with our newly invented standards. Really, I don't understand why you wrote this. Greylisting already exists. This would just make it _less_ of a problem. By greylisting from /27 netblocks, you wouldn't block any additional mail as opposed to greylisting in general; quite to the contrary. Greylisting in this manner does not require anything specific from a remote host, except that it must follow the standards as defined in RFC2821 and come back some time after it received the initial 4xx status reply. What part of that is a "newly invented standard"? Moreover, I'd like to point out that any piece of software which intends to implement some anti-spam measures will have to interpret some specific standard more strictly than required by the relevant RFCs so as to be able to distinguish spambots from human beings. There is no way around that, save making degrading some human being to "anti-spam measure for the Debian Project" and requiring him or her to manually approve each and every email to our mailinglists. I don't think you want that. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378167: ITP: sudoku -- console based sudoku
Date: Fri, 14 Jul 2006 23:25:53 +0200 Nicolas François <[EMAIL PROTECTED]> wrote: > On Fri, Jul 14, 2006 at 05:34:16PM +0200, Nacho Barrientos Arias wrote: > > Nicolas François <[EMAIL PROTECTED]> wrote: > > > > > Package: wnpp > > > Severity: wishlist > > > Owner: "Nicolas François" <[EMAIL PROTECTED]> > > > > > > > > > * Package name: sudoku > > > > Isn't this package name too general? I know that the upstream name is > > this but, can't be (this name) improved to became an official Debian > > package? > > > > Not more than a suggestion, > > I would have prefered a suggestion ;) > > Would sudokurse be better? Could be nice. > Should the binary be renamed too? Yes, note that in the future, 'sudoku' could be a symlink in /etc/alternatives, this link could point to an existing application that runs a 'sukoku' game, for example 'sudokurse' or 'gnudoku'. :-) Opinions from more experienced developers would be grateful. Cheers, -- Nacho Barrientos Arias <[EMAIL PROTECTED]> http://criptonita.com/~nacho
Re: greylisting on debian.org?
Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote: [...] >> Ok, now I understand. As I've already said, graylisting on /27 >> netblocks amounts to inventing new network standards, which I believe >> should go through the IETF standardization process before we block >> email from people who don't comply with our newly invented standards. > Really, I don't understand why you wrote this. > Greylisting already exists. This would just make it _less_ of a problem. > By greylisting from /27 netblocks, you wouldn't block any additional > mail as opposed to greylisting in general; quite to the contrary. > Greylisting in this manner does not require anything specific from a > remote host, except that it must follow the standards as defined in > RFC2821 and come back some time after it received the initial 4xx status > reply. What part of that is a "newly invented standard"? [...] Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: - retrying every hour for up to five days - messages are sent out from 120 different IP-addresses all living in different /27 netblocks. - retries do not happen on the same IP. Initial try IP-address #1, 2nd try IP-address #2, ... ,120th try IP-address #120 This in an extreme setup, but if the retry strategy is more complicated, e.g. every hour for 12 hours, then every two hours for 12 hours and every four hours from then on only 42 IP addresses are needed. If some (broken) caching is involved numbers go down further. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
This one time, at band camp, Andreas Metzler said:
> Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote:
> [...]
> >> Ok, now I understand. As I've already said, graylisting on /27
> >> netblocks amounts to inventing new network standards, which I believe
> >> should go through the IETF standardization process before we block
> >> email from people who don't comply with our newly invented standards.
>
> > Really, I don't understand why you wrote this.
>
> > Greylisting already exists. This would just make it _less_ of a problem.
>
> > By greylisting from /27 netblocks, you wouldn't block any additional
> > mail as opposed to greylisting in general; quite to the contrary.
>
> > Greylisting in this manner does not require anything specific from a
> > remote host, except that it must follow the standards as defined in
> > RFC2821 and come back some time after it received the initial 4xx status
> > reply. What part of that is a "newly invented standard"?
> [...]
>
> Hello,
> The following setup would be in compliance with rfc2821 but would
> not be able to deliver mail to a greylisting host:
> - retrying every hour for up to five days
> - messages are sent out from 120 different IP-addresses all living in
> different /27 netblocks.
> - retries do not happen on the same IP. Initial try IP-address #1, 2nd
> try IP-address #2, ... ,120th try IP-address #120
I suggest that when we find a domain that sends mail from 120 /27's
(roughly a /20), we worry about it then.
zgrep -E 'H=[^[:space:]]*.yahoo.com ' /var/log/exim4/mainlog* | egrep -v
'(-|=)>' | \
awk -F [ '{print $2}' | awk -F] '{print $1}' | sort -u | wc -l
2792
That's just over a /21, and they're the biggest I deal with. This is just
under a year's logs, on a fairly busy site. This site uses greylisting,
and does not use netblocks - it greylists the IP/sender/recipient tuple
as is. I have had no complaints about lost mail, although a few about
slow mail.
But that's not the entire point; there will be false positives. There are
probably false positives right now with the various other spam filters in
place, although I have no idea and can't check on them. Presumably the
sender doesn't get a notification in cases where a procmail rule or
spamassassin rule keeps a mail from hitting a list or my @debian.org
account.
With a greylisting system, there is no blackholing of mail - the sender
will get 'still retrying' DSN's, and finally a "couldn't deliver" DSN
in the above scenario. The sender is notified if there's a problem, so
long as the sending site pretends to follow the RFC.
The point is to make email useable without making it untreliable. This
way seems like a pretty good compromise to me.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: greylisting on debian.org?
On 7/15/06, Andreas Metzler <[EMAIL PROTECTED]> wrote: Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: - retrying every hour for up to five days - messages are sent out from 120 different IP-addresses all living in different /27 netblocks. - retries do not happen on the same IP. Initial try IP-address #1, 2nd try IP-address #2, ... ,120th try IP-address #120 I thought the point was that someone with such a setup is unlikely to have all 120 servers either listed on an RBL or with broken reverse DNS. And if they are, are you sure you want to receive mail from them? Greylisting everything is silly, and that's not what's being discussed here (AIUI anyway). Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378226: ITP: flickrfs -- Virtual filesystem for flickr online photosharing service.
also sprach Alan Woodland <[EMAIL PROTECTED]> [2006.07.14.1436 +0200]: > Flickrfs is a virtual filesystem which mounts on your machine like > any other partition. Partitions don't mount. On Unix, you mount filesystems. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "in the figure of the president, george w. bush, the incompetence, stupidity, and sheer inhumanity that characterize so much of america's money-mad corporate elite find their quintessentially repulsive expression." -- journalist, aftermath of katrina signature.asc Description: Digital signature (GPG/PGP)
Re: greylisting on debian.org?
Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On 7/15/06, Andreas Metzler <[EMAIL PROTECTED]> wrote: >> Hello, >> The following setup would be in compliance with rfc2821 but would >> not be able to deliver mail to a greylisting host: [...] > I thought the point was that someone with such a setup is unlikely to > have all 120 servers either listed on an RBL or with broken reverse > DNS. And if they are, are you sure you want to receive mail from them? [...] I am all for greylisting as suggested, I just wanted to clarify Thomas' claim that greylisting *can* break RFC compliant hosts, i.e. the "inventing new network standards". cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378167: ITP: sudoku -- console based sudoku
Nacho Barrientos Arias <[EMAIL PROTECTED]> writes: >> Would sudokurse be better? > > Could be nice. Please don't rename upstream software more than you must, this only leads to confusion among users. Don't come up with funny package names yourself. One should be able to see the relation between the Debian package name and the upstream name. If you have to rename the package, I would suggest using sudoku-curses, and provide an alternatives entry as Nacho suggested. Regards, -- Jorgen -- Debian GNU/Linux Developer [EMAIL PROTECTED] http://www.forcix.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
* Kurt Roeckx <[EMAIL PROTECTED]> [060715 10:22]: > I've tested this on sarge before, and it doesn't seem to work > there. But the same package on etch/sid do work. I'm guessing > the dynamic linker changed between sarge and etch. That is strange. On my sarge boxes I get: |$ ldd -r /usr/bin/ssh | libresolv.so.2 => /lib/libresolv.so.2 (0x7002c000) | libcrypto.so.0.9.7 => /usr/lib/v9/libcrypto.so.0.9.7 (0x7005) | [...] And I cannot remember having anything changed. (Also the libcrypto 0.9.6 in your ldd output looks more like woody than like sarge) Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378167: ITP: sudoku -- console based sudoku
Date: Sat, 15 Jul 2006 14:54:30 +0200 Jorgen Schaefer <[EMAIL PROTECTED]> wrote: > Nacho Barrientos Arias <[EMAIL PROTECTED]> writes: > > >> Would sudokurse be better? > > > > Could be nice. > > Please don't rename upstream software more than you must, this > only leads to confusion among users. Don't come up with funny > package names yourself. One should be able to see the relation > between the Debian package name and the upstream name. I agree, better 'sudoku-curses' (or similar) than 'sudokurse' or other funny names. Cheers, -- Nacho Barrientos Arias <[EMAIL PROTECTED]> http://criptonita.com/~nacho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Andreas Metzler <[EMAIL PROTECTED]> writes: > This in an extreme setup, ...or a setup designed to be used as an argument against greylisting. -- Stig Sandbeck Mathisen <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378167: ITP: sudoku -- console based sudoku
On Fri, 14 Jul 2006 23:25:53 +0200, Nicolas François <[EMAIL PROTECTED]> wrote: > On Fri, Jul 14, 2006 at 05:34:16PM +0200, Nacho Barrientos Arias wrote: > > Nicolas François <[EMAIL PROTECTED]> wrote: > > > * Package name: sudoku > > Isn't this package name too general? I know that the upstream name is > > this but, can't be (this name) improved to became an official Debian > > package? > I would have prefered a suggestion ;) > > Would sudokurse be better? > Should the binary be renamed too? Just for the record: Sudoku is the name coined by Nikoli, the puzzle magazine which introduced the puzzle from the US to Japan. Like all other stuffs from Japan, it is not originated from Japan. I am not a lawyer, but if you package it, expect a submarine patent. Sudoku is the abbreviation of "Suji wa dokusin ni kagiru", which means "a digit is best if it is not married", which implies that there is only one digit in each grid of the puzzle. Only the editors of Nikoli use the name sudoku; others call the puzzle "nampure", which is the Japanese abbreviation of "number place", which is believed the original name of the puzzle. -- Oohara Yuuma <[EMAIL PROTECTED]> Lord, what fools these mortals be! --- William Shakespeare, "A Midsummer-Night's Dream" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378379: ITP: jlj -- a command-line livejournal client
Package: wnpp Severity: wishlist Owner: Michael Stevens <[EMAIL PROTECTED]> * Package name: jlj Version : 2.12 Upstream Author : [EMAIL PROTECTED] * URL : http://patsy.cis.rit.edu/Software/perl/#jlj * License : Freeware Description : a command-line livejournal client JLJ is Jerry's LiveJournal entry system. It is very simple to use. Just setup a .livejournal.rc file in your home directory with your username and password, and run the jlj script. Downloadable from http://patsy.cis.rit.edu/Software/perl/#jlj License is "All of these are completely FREEWARE. Use them all you want, send me stuff only if you want.. an e-mail would be nice. :] ENJOY!" -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Getting the buildds to notice new architectures in a package
Hello, Package asis (=3.15p-10) supports i386, kfreebsd-i386, sparc, and powerpc. I uploaded the next version (=2005-3) a couple of days ago. It adds support for more architectures, namely: amd63, hppa, and ia64. I notice that the buildds have successfully built the powerpc and sparc packages, but seem to ignore the new architectures. I am waiting for all architectures to be rebuilt so that I can re-upload adacontrol, which build-depends on asis. In the mean time, adacontrol has a RC bug #378160 because of this problem. Where should I ask for help? Neither buildd.debian.org nor www.debian.org/devel/buildd, mention where the buildd admins can be reached; and lists.debian.org does not have a "buildd@" list. I will upload ~20 source packages in the next few weeks, adding support for more architectures to each package. So I'm really looking for a general solution and not one that only applies to asis. Thanks for any help. PS. Please reply to me directly, as well as to the list. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting the buildds to notice new architectures in a package
Ludovic Brenta wrote: > Hello, Hi Ludovic > Package asis (=3.15p-10) supports i386, kfreebsd-i386, sparc, and > powerpc. > > I uploaded the next version (=2005-3) a couple of days ago. It adds > support for more architectures, namely: amd63, hppa, and ia64. You should contact the buildd maintainers (actually the Packages-arch-specific maintainers [1]) when you add support for an architecture. > I notice that the buildds have successfully built the powerpc and > sparc packages, but seem to ignore the new architectures. I am > waiting for all architectures to be rebuilt so that I can re-upload > adacontrol, which build-depends on asis. In the mean time, adacontrol > has a RC bug #378160 because of this problem. > > Where should I ask for help? Neither buildd.debian.org nor > www.debian.org/devel/buildd, mention where the buildd admins can be > reached; and lists.debian.org does not have a "buildd@" list. @buildd.debian.org is the way buildd admins can be reached. > I will upload ~20 source packages in the next few weeks, adding > support for more architectures to each package. So I'm really looking > for a general solution and not one that only applies to asis. This is already known by the Release Team, I'm not sure if the news has already reached the P-a-s maintainers... > PS. Please reply to me directly, as well as to the list. Ok. Cheers Luk [1] These maintainers are listed at the top of the file http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Do you dream about retiring early?
internet marketers, Do you dream about retiring early? We have the leads, business, automated systems, and product to help you do it. We charge nothing to send you more information. Our team has over 8 years of proven success; we will share all. Get more now:: http://windows.team-toolbox.net/[EMAIL PROTECTED] Pro Systems [EMAIL PROTECTED] Already Toured? Re-Tour By Clicking Here: http://windows.team-toolbox.net/[EMAIL PROTECTED]&u=3 You are receiving this message because you have either signed up to receive information from us or opted-in to a third-party. To be removed from this users list or notify us that this is Unsolicited, please see the link below. Pro Systems Pro Systems Inc 1399 Green Valley Parkway Henderson, NV 89052 http://windows.team-toolbox.net/imout/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Greylisting already exists. This would just make it _less_ of a problem. > > By greylisting from /27 netblocks, you wouldn't block any additional > mail as opposed to greylisting in general; quite to the contrary. Yes, I understand. What I'm saying is that the confining the graylisting to /27 netblocks instead of per-host, while an improvement, is not enough of an improvement for me to say, "yes, what a wonderful idea graylisting is." Or rather, it *is* a wonderful idea, but I believe that conforming to network protocols is an even more wonderful idea. When you say "graylisting already exists", you seem to be ignoring the possibility that we could have no graylisting. It's not like we are somehow obliged to choose a graylisting "solution". > Greylisting in this manner does not require anything specific from a > remote host, except that it must follow the standards as defined in > RFC2821 and come back some time after it received the initial 4xx status > reply. What part of that is a "newly invented standard"? The standards do *not* say that the remote host must resend the message from the same host, or the same /27 netblock. It is this requirement which is newly invented. > Moreover, I'd like to point out that any piece of software which intends > to implement some anti-spam measures will have to interpret some > specific standard more strictly than required by the relevant RFCs so as > to be able to distinguish spambots from human beings. There is no way > around that, save making degrading some human being to "anti-spam > measure for the Debian Project" and requiring him or her to manually > approve each and every email to our mailinglists. I don't think you want > that. I can just hear George Bush using this argument. "We have no way of imposing our will on evil-person so-and-so except by starting a war and killing millions of people, so, golly shucks, we just have to start the war. Sorry guys!" Saying that there is no way to meet your goals other than by doing some bad thing does not somehow eliminate the badness of the thing. It is you who wants to avoid cooperating with the IETF on anti-spam measures, finding solutions that perhaps can work for the whole network. Not me. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
Stephen Gran <[EMAIL PROTECTED]> writes: > I suggest that when we find a domain that sends mail from 120 /27's > (roughly a /20), we worry about it then. An excellent strategy. Do you have some mechanism in place to detect such a case when or if it happens? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: gzrt -- gzip recovery toolkit
On Thu, 2006-07-13 at 19:35 +0800, Paul Wise wrote: > Please install cpio 2.5 or higher to facilitate recovery from damaged > gzipped tarballs. I will drop the version from the description and add cpio to the suggests. I added the suggestion to the description because I guess that .tar.gz will be the most common type of file being recovered and because suggests/recommends do not tell humans exactly how/why cpio is useful to install alongside gzrt. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: greylisting on debian.org?
Quoting Wolfgang Lonien ([EMAIL PROTECTED]): > Hi all, > > this is maybe the wrong group for it (sorry in that case), but: > > Do we use greylisting on the @debian.org domain and especially on > @lists.debian.org? So, up to now, we've found Thomas Bushnell who seems really hardly voting against greylisting on Debian hosts, with arguments about it breaking established standards. I personnally find these arguments very nitpicking and mostly aimed at finding a justification for an opinion that will definitely not change. So far and unless I forget someone, I haven't seen much other people being strongly opposed to greylisting on Debian hosts, especially with the setup described by Pierre Habouzit (greylisting only "suspicious" hosts). Isn't it time to move on? signature.asc Description: Digital signature
Challenge: Binary free uploading
Hi all, At https://wiki.ubuntu.com/NoMoreSourcePackages is a description of the new world order for Ubuntu packages -- which will simplify making changes to Ubuntu packages to a matter of simply committing the change to the source repository with bzr, and running a new command something like "src publish edgy" to instruct the autobuilders to grab the source from the bzr repository, create a traditional source package, and start building it for all architectures. We've recently seen an example of someone using some general features of the bug tracking system to mirror LaunchPad's features wrt tracking the status on other BTSes [0] -- what I'm wondering is if we can't manage to hack up a similar feature to that one for Debian with our current tools. The idea would be, I guess, to be able to setup pbuilder on a server somewhere, have it watch for a build instruction -- and then automatically check out the source, run a build with pbuilder, make the build log available, and if the build was successful, make the .changes file, the source and the binary packages available, so that they can be checked by hand, and uploaded to the archive. For bonus points, have the server be able to automatically do the upload by the maintainer downloading the changes, signing it, and sending the signed changes file somewhere. For more bonus points, have the server be easy to setup (apt-get install some package, edit a conguration file), and work for all sorts of different revision control systems (CVS, Subversion, git, etc). Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2006/05/msg1.html signature.asc Description: Digital signature
