Re: [Savannah-hackers-public] git-to-cvs for coreutils

[Sylvain Beucler]

On Mon, Jan 08, 2007 at 08:50:09AM +0100, Jim Meyering wrote:
> Sylvain Beucler <address@hidden> wrote:
> > I'll check the code more deeply asap, just a few comments meanwhile:
> >
> > - we install software along with security updates. In the case of git
> > we track upstream's git manually and make a debian package based on
> > backport.org's git-core/debian/ files. You want to install git-cvs
> 
> Upstream git would be nice (it's what I use), but all I need is that
> one script.
> 
> > which unfortunately requires a newer version of cvsps not packages for
> > sarge. This begins to be cumbersome so we might drop the Debian
> > packaging and install git from bare sources.
> >
> > Check ~/infra/git.txt for details.
> >
> > Anyway I mean it's Bad (tm) to install binaries (git-cvsexportcommit)
> 
> Sorry to step on your toes already.
> In case it matters, git-cvsexportcommit is a Perl script, not a binary.
> Should I put it somewhere else, for now?

Sorry I meant any kind of program. The goal is that installed programs
are tracked/registered somewhere, and easily/automatically
upgradable. Otherwise we'll most probably forget about the program and
stop maintaining it.
Most often this means we use Debian packages.

In this case we can modify the Debian packaging in
/vservers/builder/,or just install from sources (make && make
install). I just don't feel like installing gcc directly in the
cvs/git vserver, so this may complicate things. Or, you can volunteer
for keeping on eye on this program and upgrade it on a regular basis,
and document its existence in the infra/git.txt documentation :)

> > without a security track. Feel free to install software but setup
> > security/updates alongside :)
> >
> > - I try to imagine how this could then be automated. I'm thinking of
> > something smilar to CVS commitinfo/loginfo: 'update' would then be a
> > wrapper script generated by Savane, calling your unmodified script
> > with command line arguments. It would be good then to be able to
> > control your script with command line arguments instead of using a
> > modified version of the script for each project.
> >
> > - I'm not sure address@hidden is a valid adress, there's no smtp
> > service for receiving mail at SV. I don't understand the issue with
> > mails "From: address@hidden", can you explain me?
> 
> I can change it to something else, if you'd like, but the default
> is unusable.
> 
> The "mail" program is not usable without -a 'From ...' because when
> sending mail to my address, it uses that same address in the From_ header.
> That would cause my mail system (or any reasonably strict anti-spam setup)
> to smtp-reject it as a forgery, since it is claiming to be from my domain
> (meyering.net), while actually coming from sv.gnu.org.
> 
> I've just fixed the update hook to work properly:
> 
>         * /srv/git/coreutils.git/hooks/update: Use "mail -a 'From ...',
>         not "mail -a 'From: ...'.

Ok (currently this is indeed not addressed with e.g. the CVS commit
hooks).  I wonder if it wouldn't make sense to accept sv.gnu.org as a
valid sender for meyering.net - since SV is kinda proxying a mail
request from you in this context. Oh well.

address@hidden can be used as a valid (and :blackhole) sender
adress I think.

Btw please update the wiki some of this is interesting.

-- 
Sylvain