On Fri, 30 May 1997, Philip Hands wrote:
> What were you trying to achieve ? --- it might be simpler than you think.
>
> I just discovered that most of my alias handling under qmail was drivel, and
> could be dome much more simply.
>
> > If someone wants to spend some time on a simple mailer ha
> > E.g. boot-floppies. I regularly receive patches from the people doing
> > the ports to other architectures. If they could merge them into the
> > CVS repository, they needn't wait until I released a new version.
>
> What provision do you suggest for code-review? It's important for things
> lik
> (1) user-map [if all package maintainers are local]
If you just want to be delivering mail to @packages.debian.org
(rather than -@packages.debian.org), you can deliver
to remote addresses with:
In users/assign, create one line per package:
=:alias:70:65534:/var/qmail/alias:+:fwd-:
so in th
On May 29, Bruce Perens wrote
> I must admit to not understanding what that qmail alias file is for.
> I do _all_ of my aliases with .qmail-* files .
>
> What I was trying to achieve was to have qmail forward a message without
> messing around with the headers any more than necessary. Thus, I want
On Thu, 29 May 1997, Paul Bame wrote:
> = > Should this CVS repository be mandatory, i.e. does every Debian
> = > package have to be there?
>
> A brief word of warning... (I tried CVS on dpkg a while back)
>
> The natural CVS model is to name the directory for the package,
> for example .../dpkg
> I have had a very quick look at the aegis README. It has a
> baseline (main trunk in CVS; no mention of multiple independent
> branches and back merging that I could see).
It relies on RCS or CVS for its version control, so you get access to most if
not all the features of those (or at
Philip Hands <[EMAIL PROTECTED]> writes:
[snip]
> That seems simple enough.
>
> I think your best bet is this:
>
> 1) make sure control/locals does not contain packages.debian.org
But make sure it's in control/rcpthosts, of course.
> add this line to control/virtualdomains:
> packages.debia
> What I was trying to achieve was to have qmail forward a message without
> messing around with the headers any more than necessary. Thus, I wanted
> to have a .qmail-packages-default file to handle the packages.debian.org
> domain, and that would look up the package name and map it to the maintai
Aegis looks interesting. I'd like to see how it works on top of a
physically-distributed development using CVS. Do please package it
when you have time, Phil.
Thanks
Bruce
--
Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fi
From: "Christian Hudon" <[EMAIL PROTECTED]>
> Just tell me what you want qmail to do for you and point me at the
> sh/whatever scripts you started working on.
I think we already have Joey (Martin Schulze) working on this today.
Please check with him.
Bruce
--
Bruce Perens K6BP [EMAIL
I must admit to not understanding what that qmail alias file is for.
I do _all_ of my aliases with .qmail-* files .
What I was trying to achieve was to have qmail forward a message without
messing around with the headers any more than necessary. Thus, I wanted
to have a .qmail-packages-default fil
Hi,
I have had a very quick look at the aegis README. It has a
baseline (main trunk in CVS; no mention of multiple independent
branches and back merging that I could see). It implements a per
change test rquirement (thought: what tests? that the package build?
could be done with a comm
On May 29, Bruce Perens wrote
> There actually is a packages.debian.org domain aliased on "master", I
> had problems making it work because darned qmail won't parse a full
> RFC822 address on the command line (it wants you to remove the
> comments). If someone wants to spend some time on a simple m
[EMAIL PROTECTED] said:
> I had problems making it work because darned qmail won't parse a full
> RFC822 address on the command line
What were you trying to achieve ? --- it might be simpler than you think.
I just discovered that most of my alias handling under qmail was drivel, and
could be dom
> Communication should be done via a package-specific mailing list. The
> maintainer of the package decides who has commit privileges for this
> package and who gets on this package's developers' mailing-list.
>
> This mailing list could be used as target for the bug reports against
> this package
= > Communication should be done via a package-specific mailing list. The
= > maintainer of the package decides who has commit privileges for this
= > package and who gets on this package's developers' mailing-list.
=
= The way we are currently doing it here (at Pixar) is that nobody checks
= in a
There actually is a packages.debian.org domain aliased on "master", I
had problems making it work because darned qmail won't parse a full
RFC822 address on the command line (it wants you to remove the
comments). If someone wants to spend some time on a simple mailer hack,
you can make this work.
Sven Rudolph writes:
> Communication should be done via a package-specific mailing list. The
> maintainer of the package decides who has commit privileges for this
> package and who gets on this package's developers' mailing-list.
>
> This mailing list could be used as target for the bug reports
[EMAIL PROTECTED] (Bruce Perens) writes:
> > Communication should be done via a package-specific mailing list. The
> > maintainer of the package decides who has commit privileges for this
> > package and who gets on this package's developers' mailing-list.
(And the CVS commit messages are sent to
> Communication should be done via a package-specific mailing list. The
> maintainer of the package decides who has commit privileges for this
> package and who gets on this package's developers' mailing-list.
The way we are currently doing it here (at Pixar) is that nobody checks
in an un-reviewe
[EMAIL PROTECTED] (Bruce Perens) writes:
> > E.g. boot-floppies. I regularly receive patches from the people doing
> > the ports to other architectures. If they could merge them into the
> > CVS repository, they needn't wait until I released a new version.
>
> What provision do you suggest for co
= > Should this CVS repository be mandatory, i.e. does every Debian
= > package have to be there?
A brief word of warning... (I tried CVS on dpkg a while back)
The natural CVS model is to name the directory for the package,
for example .../dpkg/ and relegate the version numbers to tags.
At least
> E.g. boot-floppies. I regularly receive patches from the people doing
> the ports to other architectures. If they could merge them into the
> CVS repository, they needn't wait until I released a new version.
What provision do you suggest for code-review? It's important for things
like boot-flopp
> Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
>
> > great. since i meet other debian developers at the linux congress, i my
> > a big friend of a cvs server with all debian packages. does anyone have
> > a server with enough hard disks and a good conection to run it ?
>
> Some problems arise
Sven Rudolph writes:
> Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
>
> > great. since i meet other debian developers at the linux congress, i my
> > a big friend of a cvs server with all debian packages. does anyone have
> > a server with enough hard disks and a good conection to run it ?
>
>
Andreas Jellinghaus <[EMAIL PROTECTED]> writes:
> great. since i meet other debian developers at the linux congress, i my
> a big friend of a cvs server with all debian packages. does anyone have
> a server with enough hard disks and a good conection to run it ?
Some problems arise:
Should this
Rob Browning writes:
> I guess I was looking for -ko, since you wouldn't want to be rewriting
> the $Id$ values for the upstream source unless you actually changed
> things, and even then it's kind of iffy since your tree has nothing to
> do with theirs. In addition, without -ko, you'd get a b
Hi.
>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
Jason> On 26 May 1997, Rob Browning wrote:
Rob> What do you do about packages whose upstream source is already
Rob> being managed by CVS and already has $Id$ markers, etc in it?
Jason> Nothing. When you check it into CVS it will rewri
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> Nothing. When you check it into CVS it will rewrite all of the $Id: $
> markers and friends to reflect your CVS tree. It shouldn't have any
> problems. You might not want that so you can turn off substitution with
> -ko I think.
I guess I was looking
Hi,
I just import the upstream version with ``cvs import -ko'', and
``cvs add'' my changes without any k options. This way the upstream
sources do not get mangled, but the debian only files come with full
RCS keywords.
manoj
>From the info pages:
File: cvs.info, Node: Substit
On 26 May 1997, Rob Browning wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
> > I would really like to get into using CVS for my package
> > development tree, but I have been held back by the hassle of
> > releasing packages.
>
> I wondered about this, and I had a question. I lo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I would really like to get into using CVS for my package
> development tree, but I have been held back by the hassle of
> releasing packages.
I wondered about this, and I had a question. I looked around in the
CVS manual a little and didn't
On May 26, Manoj Srivastava wrote
> Hi,
>
> I would really like to get into using CVS for my package
> development tree, but I have been held back by the hassle of
> releasing packages. I have no problems testing packages with
> ./debian/rules binary
> and I always used dpkg-buildpackage
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> The credit should really go to Lars Wirzenius and Ian Jackson,
> since this borrows from their work. If there is enough interest, I
> could package this up. (Oh, this is a sh script, and only needs
> dpkg-dev, no perl ;-)
Please do so. CVS is
34 matches
Mail list logo
