[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some packages that compiled fine for hurd-i386



Hello,

On Sun, Jan 23, 2005 at 01:32:05AM +0100, Physicman wrote:
> > Well, I intend to do so, so here is my first patch for the ssmtp
> > package. Dunno if the formatting is right and there are maybe other
> > problems, but it works for me.

First, off, thanks a lot for your patch and the decision to contribute!

> > Please tell me if this is the correct way to proceed, so that I can
> > continue ;)

There are some minor issues pertaining to the formalities, which I'd
like to point out:

* First off, please do not send gzipped patches to Hurd lists. Most
people on the lists don't tend to look gzipped patches. Also, people
seem to like inlined (i.e. directly in the mail body, as opposed to
attached) patches, but this is up to you.

* Try to keep the patch as small as possible. E.g., you have a
ssmtp.c.orig (along with a ssmtp.c.rej) in your patch which is
superflouos, also the .diff.gz and .dsc managed to sneak into the patch.
Just look over your patch before you send it, and strip off the unneeded
things (I do that with my preferred editor)

* Not directed at your patch, but in general: Do not include
auto-generated files in your patch, as they tend to be quite big. An
example would be changes to configure.in/configure.ac or Makefile.am,
which result in changes in configure and Makefile.in as well. Just
mention in your mail that those files need to be regenerated (and
mention the necessary command if it is non-obvious)

* Try to keep changes to the Debian Maintainer's packaging to a minimum.
It is up to him to decide how to best maintain the package. in your
case, you added a simple patch system to the package to handle your
patches. This is a noble deed, but there are some patches in the current
Debian .diff.gz already, so it would be best to just stick with that.
What you can do is split up the old patches along with your new ones,
convert the package to some patch system (like dpatch or quilt) and
submit this as a seperate wishlist bug to the maintainer. In this case,
it's of course up to the maintainer to take advantage of your work, so
asking beforehand would save you some frustration in case he declines.


Now, for the actual patch :)

It's a bit awkward to review the patch as is, as it generates new files
in debian/patches, which itself contain the real patch. I am not too
sure how to proceed here, perhaps it is best to decouple the process.
I.e. first send the actual patch for the source packages and then
(optionally) a proposed patch for the Debian package. 

So I propose you resend a cleaned up non-Debian version of the patch to
help-hurd@gnu.org, soliciting review. Afterwards (in general), you can
send a proposed patch for the Debian package (adopted to the respective
build system and taking into account possible changes to debian/control
or debian/rules and so on) to this list until further notice.

I am open to suggested on how to proceed here, what do you others think
(especially on the choice of mailing lists)?

> > BTW, I also noticed xpdf could be rebuilded without problems (it is
> > currently broken in the archive because of version conflicts).

Thanks for noting that. 

Again, thanks for your work! Does ssmtp work well for you?


cheers,

Michael



Reply to: