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 hack,
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 wanted
(1) user-map [if all package maintainers are local]
If you just want to be delivering mail to package_name@packages.debian.org
(rather than package_name-extension@packages.debian.org), you can deliver
to remote addresses with:
In users/assign, create one line per package:
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
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.
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 mailer
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
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
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
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
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 maintainer
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:
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
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/ and
Brian White [EMAIL PROTECTED] writes:
We are running cvs.debian.org over an ISDN line. Currently the only
code under it is the Deity project.
I can make other source trees and set up other users if others want to
do distributed development this way.
I need a shared CVS repository for
We are running cvs.debian.org over an ISDN line. Currently the only
code under it is the Deity project.
I can make other source trees and set up other users if others want to
do distributed development this way.
I need a shared CVS repository for boot-floppies. Especially people
who
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 CVS
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 ?
Some
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
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
= 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
[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
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-reviewed
[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 this
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
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.
= 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
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 rewrite all of
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 ?
We are running cvs.debian.org over an ISDN line. Currently the only
code under it is
We are running cvs.debian.org over an ISDN line. Currently the only
code under it is the Deity project.
I can make other source trees and set up other users if others want to
do distributed development this way.
Unfortunately, I haven't been able to set up world read access yet
because
because CVS always wants write access to the directory (for lock files)
Yep. I've seen patches for this at MIT, but I don't think they're in
the mainline... You've also got some potentially major access control
problems; look at what freebsd does, and consider that you *don't*
want general
because CVS always wants write access to the directory (for lock files)
Yep. I've seen patches for this at MIT, but I don't think they're in
the mainline... You've also got some potentially major access control
problems; look at what freebsd does, and consider that you *don't*
want
On Wed, 28 May 1997, Jim Pick wrote:
We are running cvs.debian.org over an ISDN line. Currently the only
code under it is the Deity project.
I can make other source trees and set up other users if others want to
do distributed development this way.
Unfortunately, I haven't been
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
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] 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 find
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 looked around
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:
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 for
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 for the last step, so I have
written
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 a
41 matches
Mail list logo
