problem with conntrack-0.81
laforge at netfilter.org
Fri Nov 4 21:39:36 CET 2005
On Fri, Nov 04, 2005 at 07:40:58PM +0100, Pablo Neira wrote:
> pablo at legba:~/SVN-netfilter/trunk/homepage$ make
> make -C xml
> make: Entering directory `/usr/src/SVN/trunk/homepage/xml'
> perl -I../scripts -I../../patch-o-matic-ng ../scripts/pom2docbook.pl
> --xmldir ./patch-o-matic --repository pending
> Your linux version is unknown for patch-o-matic at
> ../scripts/pom2docbook.pl line 119
> make: *** [patch-o-matic/pom-pending.xml] Error 255
> make: Leaving directory `/usr/src/SVN/trunk/homepage/xml'
> make: *** [all] Error 2
> any clue on what's wrong?
it tries to execute patch-o-matic-ng, but doesn't find a linux kernel in
the default location (don't know where the default is, you'd have to
check the sources).
this is for auto-creating the xml/html pages from the patch-o-matic
> > The more important issues is, how we're going to handle signing and
> > uploading of the respective files to ftp and http server. At the
> > moment, only the core team can sign releases (and has the respective
> > upload permissions).
> During the WS you told me that you needed someone that could do the
> releasing stuff. Well, I don't know if this could help but if you
> consider that I could that such work, what will it consist on?
well, basicaully it would mean that you'd be doing the 'make distrib',
uploading the files to the http/ftp server, updating the homepage xml,
rebuilding html from the xml, and (at least in the iptables case)
manually write the changelog based on the diff to the previous version
and the svn commit messages.
PGP/GPG signign is an issue, and currently we only have one key for the
coreteam. Maybe we should create a separate 'release signing key' that
would be kept with the releasemaster (e.g. you).
An alternative was to wait for somebody in the netfilter project to send
you the signed released file, and you would just do the
- Harald Welte <laforge at netfilter.org> http://netfilter.org/
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20051104/1e8c0b77/attachment.pgp
More information about the netfilter-devel