<!entity p-intro SYSTEM "privoxy.sgml">
<!entity history SYSTEM "history.sgml">
<!entity seealso SYSTEM "seealso.sgml">
-<!entity p-version "3.0.30">
+<!entity p-version "3.0.34">
<!entity p-status "UNRELEASED">
<!entity % p-not-stable "INCLUDE">
<!entity % p-stable "IGNORE">
Purpose : developer manual
- Copyright (C) 2001-2020 Privoxy Developers https://www.privoxy.org/
+ Copyright (C) 2001-2021 Privoxy Developers https://www.privoxy.org/
See LICENSE.
========================================================================
<!-- Completely the wrong markup, but very little is allowed -->
<!-- in this part of an article. FIXME -->
<ulink url="https://www.privoxy.org/user-manual/copyright.html">Copyright</ulink>
- &my-copy; 2001-2020 by
+ &my-copy; 2001-2021 by
<ulink url="https://www.privoxy.org/">Privoxy Developers</ulink>
</subscript>
</pubdate>
Before pushing stuff, please rebase it on a current master so we get
an uncomplicated commit history. Avoid merges where possible.
</para>
+ <para>
+ Here's an example git sesssion that should result in a merge-free history:
+ </para>
+ <programlisting>
+fk@t520 ~/git/privoxy $git checkout master
+Switched to branch 'master'
+Your branch is up to date with 'origin/master'.
+# Make sure you have the latest changes
+fk@t520 ~/git/privoxy $git pull
+Already up to date.
+# Create a local banch for changes
+fk@t520 ~/git/privoxy $git checkout -b local-branch
+Switched to a new branch 'local-branch'
+# Create some change
+fk@t520 ~/git/privoxy $gmake dok dok-tidy
+[...]
+# Review your change
+fk@t520 ~/git/privoxy $git diff
+[...]
+# Commit your changes if they look goood
+fk@t520 ~/git/privoxy $git commit -m "developer-manual: Regenerate" doc/webserver/
+[local-branch 1abb7316] developer-manual: Regenerate
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+# Review your commit
+fk@t520 ~/git/privoxy $git show
+[...]
+# Go to the master branch
+fk@t520 ~/git/privoxy $git checkout master
+Switched to branch 'master'
+Your branch is up to date with 'origin/master'.
+# Make sure you are still in sync
+fk@t520 ~/git/privoxy $git pull
+[...]
+Already up to date.
+# Apply the commit you made to the local-branch
+fk@t520 ~/git/privoxy $git cherry-pick local-branch
+[master 046e85e2] developer-manual: Regenerate
+ Date: Tue Dec 15 05:10:07 2020 +0100
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+# Make sure the history looks as expected
+fk@t520 ~/git/privoxy $git log -p
+# Finally push your change to the Privoxy repository
+fk@t520 ~/git/privoxy $git push
+[...]
+# Go back to the local branch
+fk@t520 ~/git/privoxy $git checkout local-branch
+# Rebase on top of master and continue hacking
+fk@t520 ~/git/privoxy $git rebase master
+Successfully rebased and updated refs/heads/local-branch.
+</programlisting>
<!--
<para>
Branches are used to fork a sub-development path from the main trunk.
course this, the <citetitle>developer-manual</citetitle> in this format.
The <citetitle>README</citetitle>, <citetitle>AUTHORS</citetitle>,
<citetitle>INSTALL</citetitle>,
- <citetitle>privoxy.1</citetitle> (man page), and
+ <citetitle>privoxy.8</citetitle> (man page), and
<citetitle>config</citetitle> files are also now maintained as Docbook
SGML. These files, when built, in the top-level source directory are
generated files! Also, the <application>Privoxy</application> <filename>index.html</filename> (and a
2020-12-14 12:16:44: Executed 1087 regression tests. Skipped 115. 1085 successes, 2 failures.
# Repeat one of the failing tests and get a curl command to quickly reproduce the problem
# without causing too much log noise.
-fk@t520 ~ $privoxy-regression-test.pl --test-number 785 --verbose --debug 39
+fk@t520 ~ $privoxy-regression-test.pl --test-number 785 --verbose --debug 4
2020-12-14 12:17:55: Asking Privoxy for the number of action files available ...
[...]
2020-12-14 12:17:56: Executing regression tests ...
2020-12-14 12:17:56: Ooops. Expected removal but: 'Referer: https://p.p/' is still there.
2020-12-14 12:17:56: Failure for test 785 (0/13/5). Header 'Referer: https://p.p/' and tag 'hide-referrer{conditional-block}'
2020-12-14 12:17:56: Executed 1 regression tests. Skipped 1201. 0 successes, 1 failures.
- </programlisting>
+</programlisting>
<para>
Use the if the <command>--privoxy-address</command> option if the
- http_proxy environment variable isn't configured.
+ http_proxy environment variable isn't configured and you don't want
+ to use the default (http://127.0.0.1:8118/).
</para>
</sect2>
</listitem>
<listitem>
<para>
- Update the code status (CODE_STATUS="xxx") in configure.in to one of
+ Update the code status (CODE_STATUS="xxx") in <filename>configure.in</filename> to one of
"alpha", "beta" or "stable".
</para>
</listitem>
<para>
If action file processing has changed and is not backward-compatible,
make sure the "for-privoxy-version=x.y.z" minimum version number in
- default.action.master has been updated:
+ <filename>default.action.master</filename> has been updated:
</para>
<programlisting>
{{settings}}
Create the change log:
</para>
<programlisting>
- $ git tag
- # to see the tags
- $ git log [last release tag]..HEAD > /tmp/log
- # get the commit log since the last release
- $ utils/makeChangeLog /tmp/log > /tmp/change.log
- # reformat the commit log
+$ git tag
+# to see the tags
+$ git log [last release tag]..master > /tmp/log
+# get the commit log since the last release
+$ utils/makeChangeLog /tmp/log > /tmp/change.log
+# reformat the commit log
</programlisting>
<para>
Edit <filename>/tmp/change.log</filename> to remove trivial
<filename>doc/source/changelog.sgml</filename>:
</para>
<programlisting>
- $ utils/changelog2doc.pl /tmp/change.log >| doc/source/changelog.sgml
+$ utils/changelog2doc.pl /tmp/change.log >| doc/source/changelog.sgml
</programlisting>
</listitem>
<listitem>
make sure noteworthy changes are referenced.
</para>
</listitem>
+ <listitem>
+ <para>
+ Update the announcement at <filename>doc/webserver/announce.txt</filename>.
+ </para>
+ </listitem>
<listitem>
<para>
All documentation should be rebuilt:
<programlisting>
- $ make man
- $ make dok
- $ make dok-man
- $ make dok-tidy
- $ make config-file
+$ make man
+$ make dok
+$ make dok-man
+$ make dok-tidy
+$ make config-file
</programlisting>
Finished docs should be then be committed to Git (for those
without the ability to build these). Some docs may require
link from the main page since we need to keep manuals for various
versions available). The CGI pages will link to something like
<literal>https://www.privoxy.org/$(VERSION)/user-manual/</literal>. This
- will need to be updated for each new release. There is no Makefile
- target for this at this time!!! It needs to be done manually.
+ needs to be updated for each new release and is done with the
+ <quote>webserver</quote> target.
</para>
</listitem>
<listitem>
<para>
Tag all files in Git with the version number with
- <quote><command>git tag v_X_Y_Z</command></quote>.
+ <quote><command>git tag -s v_X_Y_Z</command></quote>.
Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
</para>
</listitem>
+ <listitem>
+ <para>
+ Push the tag to the remote with
+ <quote><command>git push origin v_X_Y_Z</command></quote>.
+ </para>
+ </listitem>
<listitem>
<para>
On the webserver, copy the user manual to a new top-level directory
</para>
<programlisting>
- mkdir dist # delete or choose different name if it already exists
- cd dist
- git clone https://www.privoxy.org/git/privoxy.git
- cd privoxy
- git checkout v_X_Y_Z
+mkdir dist # delete or choose different name if it already exists
+cd dist
+git clone https://www.privoxy.org/git/privoxy.git
+cd privoxy
+git checkout v_X_Y_Z
</programlisting>
<para>
Also suggested: <filename>Developer Manual</filename>
(doc/webserver/developer-manual) and <filename>ChangeLog</filename>
(top-level directory). <filename>FAQ</filename> and the manuals are
- HTML docs. There are also text versions in
- <filename>doc/text/</filename> which could conceivably also be
- included.
+ HTML docs.
</para>
<para>
The documentation has been designed such that the manuals are linked
</listitem>
<listitem>
<para>
- Other configuration files (<filename>default.action</filename> and
+ Other configuration files (<filename>default.action</filename>,
+ <filename>regression-tests.action</filename> and
<filename>default.filter</filename>) should be installed as the new
defaults, but all previously installed configuration files should be
preserved as backups. This is just good manners :-) These files are
<para>
First, <emphasis>make sure that you have freshly exported the right
version into an empty directory</emphasis>. (See "Building and releasing
- packages" above). Then run:
+ packages" above). Then run from that directory:
</para>
<programlisting>
- cd current
- autoheader && autoconf && ./configure
+autoheader && autoconf && ./configure
</programlisting>
<para>
Then do:
</para>
<programlisting>
- make tarball-dist
-</programlisting>
- <para>
- To upload the package to Sourceforge, simply issue
- </para>
- <programlisting>
- make tarball-upload
+make tarball-dist
</programlisting>
- <para>
- Go to the displayed URL and release the file publicly on Sourceforge.
- For the change log field, use the relevant section of the
- <filename>ChangeLog</filename> file.
- </para>
</sect3>
- <sect3 id="newrelease-rpm"><title>SuSE, Conectiva or Red Hat RPM</title>
+ <sect3 id="NEWRELEASE-WINDOWS"><title>Windows</title>
+ <!-- so annoying: docbook generated ids are UPPERCASE so
+ links to "whatever.html#idtag" DO NOT WORK!!
+ They have to be "whatever.html#IDTAG".
+ So be consistent and use uppercase on the definition.
+ -->
<para>
- In following text, replace <replaceable class="parameter">dist</replaceable>
- with either <quote>rh</quote> for Red Hat or <quote>suse</quote> for SuSE.
+ Note that the docbook generated files might need some hand editing,
+ so the Windows build makefile does not rebuild the docs.
</para>
+
<para>
First, <emphasis>make sure that you have freshly exported the right
version into an empty directory</emphasis>. (See "Building and releasing
packages" above).
</para>
+
<para>
- As the only exception to not changing anything after export from Git,
- now examine the file <filename>privoxy-</filename><replaceable class="parameter">dist</replaceable><filename>.spec</filename>
- and make sure that the version information and the RPM release number are
- correct. The RPM release numbers for each version start at one. Hence it must
- be reset to one if this is the first RPM for
- <replaceable class="parameter">dist</replaceable> which is built from version
- X.Y.Z. Check the
- <ulink url="https://sourceforge.net/projects/ijbswa/files/">file
- list</ulink> if unsure. Else, it must be set to the highest already available RPM
- release number for that version plus one.
+ Check that you have the current versions of the
+ <ulink url="https://sourceforge.net/projects/nsis/files/NSIS%203/">
+ NSIS installer</ulink>,
+ <ulink url="https://ftp.pcre.org/pub/pcre/">PCRE library</ulink>,
+ <ulink url="https://tls.mbed.org/download">MBED TLS library</ulink>,
+ <ulink url="https://github.com/google/brotli/releases">
+ Brotli library</ulink>,
+ and that the <emphasis>MAKENSIS</emphasis> evar in
+ <filename>windows/GNUMakefile</filename>
+ points to the NSIS installer program. (See the
+ <ulink url="../user-manual/installation.html#WINBUILD-CYGWIN">
+ <emphasis>Building from Source / Windows</emphasis></ulink>
+ section of the User Manual for details.)
</para>
+
<para>
- Then run:
+ Then you can build the package. This is fully automated, and is
+ controlled by <filename>windows/GNUmakefile</filename>.
+ All you need to do is:
</para>
- cd current
- autoheader && autoconf && ./configure
+ <programlisting>
+cd windows
+make
</programlisting>
<para>
- Then do
+ Now you can manually rename <filename>privoxy_setup.exe</filename> to
+ <filename>privoxy_setup_X.Y.Z.exe</filename>, and the <filename>build</filename>
+ directory to <filename>privoxy_X.Y.Z</filename>.
+ Create a .zip file of the newly renamed <filename>privoxy_X.Y.Z</filename> directory,
+ GPG sign the installer and zip file,
</para>
- <programlisting>
- make <replaceable class="parameter">dist</replaceable>-dist
+ <programlisting>
+gpg --armor --detach --sign <filename>privoxy_setup_X.Y.Z.exe</filename>
+gpg --armor --detach --sign <filename>privoxy_X.Y.Z.zip</filename>
</programlisting>
<para>
- To upload the package to Sourceforge, simply issue
+ and upload the files to SourceForge.
</para>
- <programlisting>
- make <replaceable class="parameter">dist</replaceable>-upload <replaceable class="parameter">rpm_packagerev</replaceable>
-</programlisting>
+
<para>
- where <replaceable class="parameter">rpm_packagerev</replaceable> is the
- RPM release number as determined above.
- Go to the displayed URL and release the file publicly on Sourceforge.
- Use the release notes and change log from the source tarball package.
+ When releasing the package on SourceForge, use the release notes
+ and Change Log from the source tarball package.
</para>
</sect3>
- <sect3 id="newrelease-solaris"><title>Solaris</title>
+ <sect3 id="newrelease-debian"><title>Debian</title>
<para>
- Login to Sourceforge's compilefarm via ssh:
+ Using git-buildpackage we start with a clone of the last Debian version:
</para>
- <programlisting>
- ssh cf.sourceforge.net
+ <programlisting>
+gbp clone https://salsa.debian.org/debian/privoxy.git
+cd privoxy
</programlisting>
<para>
- Choose the right operating system (not the Debian one).
- When logged in, <emphasis>make sure that you have freshly exported the right
- version into an empty directory</emphasis>. (See "Building and releasing
- packages" above). Then run:
+ or if the repository is already there
</para>
- cd current
- autoheader && autoconf && ./configure
+ <programlisting>
+cd privoxy
+gbp pull
</programlisting>
<para>
- Then run
+ Now import the newly released upstream tarball via debian/watch file:
</para>
- gmake solaris-dist
+ <programlisting>
+gbp import-orig --uscan
</programlisting>
<para>
- which creates a gzip'ed tar archive. Sadly, you cannot use <command>make
- solaris-upload</command> on the Sourceforge machine (no ncftpput). You now have
- to manually upload the archive to Sourceforge's ftp server and release
- the file publicly. Use the release notes and Change Log from the
- source tarball package.
+ Next update all Debian quilt patches to the new version:
</para>
- </sect3>
-
- <sect3 id="NEWRELEASE-WINDOWS"><title>Windows</title>
- <!-- so annoying: docbook generated ids are UPPERCASE so
- links to "whatever.html#idtag" DO NOT WORK!!
- They have to be "whatever.html#IDTAG".
- So be consistent and use uppercase on the definition.
- -->
+ <programlisting>
+while quilt push; do quilt refresh; done
+</programlisting>
<para>
- Note that the docbook generated files might need some hand editing,
- so the Windows build makefile does not rebuild the docs.
+ If some patch is no longer required (because it is already merged
+ upstream), it can be removed using
</para>
-
+ <programlisting>
+quilt delete XX_patchname.patch
+git rm debian/patches/XX_patchname.patch
+</programlisting>
<para>
- First, <emphasis>make sure that you have freshly exported the right
- version into an empty directory</emphasis>. (See "Building and releasing
- packages" above).
- <!-- XXX ??? are we still basing releases off a tarball???
- -->
+ If the patch needs modification, you can apply, edit and update it with
</para>
+ <programlisting>
+quilt push -f
+quilt edit some_file
+quilt refresh
+</programlisting>
<para>
- Then you can build the package. This is fully automated, and is
- controlled by <filename>windows/GNUmakefile</filename>.
- All you need to do is:
+ until
</para>
<programlisting>
- cd windows
- make
+while quilt push; do quilt refresh; done
</programlisting>
<para>
- Now you can manually rename <filename>privoxy_setup.exe</filename> to
- <filename>privoxy_setup_X.Y.Z.exe</filename>, and the <filename>build</filename>
- directory to <filename>privoxy_X.Y.Z</filename>.
- Create a .zip file of the newly renamed <filename>privoxy_X.Y.Z</filename> directory,
- GPG sign the installer and zip file,
+ succeeds. Then you can
</para>
<programlisting>
- $ gpg --armor --detach --sign <filename>privoxy_setup_X.Y.Z.exe</filename>
- $ gpg --armor --detach --sign <filename>privoxy_X.Y.Z.zip</filename>
+quilt pop -a
</programlisting>
<para>
- and upload the files to SourceForge.
+ Now add a new entry to the debian/changelog representing the new
+ version:
</para>
-
+ <programlisting>
+dch -v &p-version;-1
+</programlisting>
<para>
- When releasing the package on SourceForge, use the release notes
- and Change Log from the source tarball package.
+ and describe what you did before and don't forget to git commit all
+ changes.
+ </para>
+ <para>
+ Now you can build the package on the local machine using
+ </para>
+ <programlisting>
+gbp buildpackage -us -uc
+</programlisting>
+ <para>
+ You should check for warnings using
+ </para>
+ <programlisting>
+lintian -iI ../build-area/privoxy_&p-version;-1_amd64.changes
+</programlisting>
+ <para>
+ Maybe rebuild the package in different defined cowbuilder environments
+ like
+ </para>
+ <programlisting>
+sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_&p-version;-1.dsc
+</programlisting>
+ <para>
+ And try to run autopackage testing suite on the result:
+ </para>
+ <programlisting>
+autopkgtest /var/cache/pbuilder/result/privoxy_&p-version;-1_amd64.changes -s -- schroot sid
+</programlisting>
+ <para>
+ Or just push the changes to salsa.debian.org, where a CI pipeline is
+ defined for the package, that builds and tests it.
+ </para>
+ <para>
+ If everything is okay, run cowbuilder with i386 and amd64 environments
+ for current Debian stable release and build
+ privoxy_&p-version;-1_i386.deb and privoxy_&p-version;-1_amd64.deb.
+ Then sign both files:
+ </para>
+ <programlisting>
+gpg --detach-sign --armor privoxy_&p-version;-1_i386.deb
+gpg --detach-sign --armor privoxy_&p-version;-1_amd64.deb
+</programlisting>
+ <para>
+ Create a README file containing the recent block from debian/changelog
+ and upload the two packages, the two signatures and the README to a
+ freshly created folder below
+ https://sourceforge.net/projects/ijbswa/files/Debian/
</para>
- </sect3>
- <sect3 id="newrelease-debian"><title>Debian</title>
+ <sect4 id="snapshot-debian"><title>Debian GIT Snapshot</title>
<para>
- First, <emphasis>make sure that you have freshly exported the
- right version into an empty directory</emphasis>. (See
- "Building and releasing packages" above). Then add a log
- entry to <filename>debian/changelog</filename>, if it is not
- already there, for example by running:
+ For building just a git snapshot build the following workflow may be
+ useful. First create a build environment, for this you may have to
+ run the following commands:
</para>
- <programlisting>
- debchange -v &p-version;-&p-status;-1 "New upstream version"
+ <programlisting>
+sudo apt install build-essential devscripts
+sudo apt-get build-dep privoxy
</programlisting>
<para>
- Then, run:
+ After this enter the checked out privoxy git tree and check that all
+ (new) build dependencies are met:
</para>
- dpkg-buildpackage -rfakeroot -us -uc -b
+ <programlisting>
+dpkg-checkbuilddeps
</programlisting>
<para>
- This will create
- <filename>../privoxy_&p-version;-&p-status;-1_i386.deb</filename>
- which can be uploaded. To upload the package to Sourceforge, simply
- issue
+ If something is missing, just add it using
</para>
- <programlisting>
- make debian-upload
+ <programlisting>
+sudo apt install foobar
+</programlisting>
+ <para>
+ Now you may update debian/changelog, especially the version number
+ using
+ </para>
+ <programlisting>
+dch
+</programlisting>
+ <para>
+ and finally build the package:
+ </para>
+ <programlisting>
+debuild -us -uc -b
</programlisting>
+ <para>
+ If everything went okay, you may find the resulting Debian package in
+ the parent directory.
+ </para>
+ <para>
+ You may want to clean up the build tree using
+ </para>
+ <programlisting>
+debian/rules clean
+</programlisting>
+ <para>
+ And maybe repair some artefacts using one or both of the following
+ commands:
+ </para>
+ <programlisting>
+git reset --hard
+git clean -fd
+</programlisting>
+ </sect4>
</sect3>
- <sect3 id="newrelease-macosx"><title>Mac OS X</title>
+ <sect3 id="newrelease-macosx"><title>macOS / OS X</title>
<para>
First, <emphasis>make sure that you have freshly exported the right
version into an empty directory</emphasis>. (See "Building and releasing
packages" above).
</para>
<para>
- There are three modules available in the CVS repository backups for use on Mac
- OS X, though technically only two of them generate a release (the other
- can be used to install from source).
+ The OSXPackageBuilder module can generate OS X installer packages
+ supporting all Macs running OS X 10.4 and above. Obtain it from Git as
+ follows into a folder parallel to the exported privoxy source:
</para>
- <sect4 id="OS-X-OSXPackageBuilder-module">
- <title>OSXPackageBuilder module (Documentation out of date)</title>
- <para>
- The OSXPackageBuilder module generates OS X installer packages
- supporting all Macs running OS X 10.4 and above. Obtain it from CVS as
- follows into a folder parallel to the exported privoxy source:
- </para>
- <programlisting>
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder
-</programlisting>
- <para>
- The module contains complete instructions on its usage in the file
- <filename>OS X Package Builder HOWTO.txt</filename>.
- </para>
- <para>
- Once the package(s) have been generated, you can then upload them
- directly to the Files section of the Sourceforge project in the
- Macintosh (OS X) folder. Each new version release of Privoxy should
- have a new subfolder created in which to store its files. Please
- ensure that the folder contains a readme file that makes it clear
- which package is for whichversion of OS X.
- </para>
- </sect4>
- <sect4 id="OS-X-osxsetup-module">
- <title>osxsetup module (DEPRECATED) (Documentation out of date)</title>
- <para>
- <emphasis>This module is deprecated since the installer it generates
- places all Privoxy files in one folder in a non-standard location, and
- supports only Intel Macs running OS X 10.6 or higher.</emphasis>
- </para>
- <para>
- Check out the module from CVS as follows into a folder parallel to the
- exported privoxy source:
- </para>
- <programlisting>
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
-</programlisting>
- <para>
- Then run:
- </para>
- <programlisting>
- cd osxsetup
- build
-</programlisting>
- <para>
- This will run <filename>autoheader</filename>, <filename>autoconf</filename>
- and <filename>configure</filename> as well as <filename>make</filename>.
- Finally, it will copy over the necessary files to the ./osxsetup/files
- directory for further processing by <filename>PackageMaker</filename>.
- </para>
- <para>
- Bring up PackageMaker with the PrivoxyPackage.pmsp definition file,
- modify the package name to match the release, and hit the "Create
- package" button. If you specify ./Privoxy.pkg as the output package
- name, you can then create the distributable zip file with the command:
- </para>
- <programlisting>
- zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
-</programlisting>
- <para>
- You can then upload this file directly to the Files section of the
- Sourceforge project in the Macintosh (OS X) folder. Each new version
- release of Privoxy should have a new subfolder created in which to
- store its files.
- Please ensure that the folder contains a readme file that makes it
- clear which version(s) of OS X the package supports.
- </para>
- </sect4>
- <sect4 id="OS-X-macsetup-module">
- <title>macsetup module (Documentation out of date)</title>
- <para>
- The macsetup module is ideal if you wish to build and install Privoxy
- from source on a single machine.
- </para>
- <para>
- Check out the module from CVS as follows into a folder parallel to the
- exported privoxy source:
- </para>
- <programlisting>
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup
+ <programlisting>
+git clone ssh://git@git.privoxy.org:23/git/OSXPackageBuilder.git
</programlisting>
- <para>
- The module contains complete instructions on its usage in its
- <filename>README</filename> file. The end result will be the
- exported version of Privoxy installed on the build machine.
- </para>
- </sect4>
+ <para>
+ The module contains complete instructions on its usage in the file
+ <filename>OS X Package Builder HOWTO.txt</filename>.
+ </para>
+ <para>
+ Once the package(s) have been generated, you can then upload them
+ directly to the Files section of the Sourceforge project in the
+ Macintosh (OS X) folder. Each new version release of Privoxy should
+ have a new subfolder created in which to store its files. Please
+ ensure that the folder contains a readme file that makes it clear
+ which package is for which version of OS X.
+ </para>
</sect3>
<sect3 id="newrelease-freebsd"><title>FreeBSD</title>
<title>Uploading and Releasing Your Package</title>
<para>
After the package is ready, it is time to upload it
- to SourceForge, and go through the release steps. The upload
- is done via FTP:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Upload to: <ulink url="ftp://upload.sourceforge.net/incoming">ftp://upload.sourceforge.net/incoming</ulink>
- </para>
- </listitem>
- <listitem>
- <para>
- user: <literal>anonymous</literal>
- </para>
- </listitem>
- <listitem>
- <para>
- password: <literal>ijbswa-developers@lists.sourceforge.net</literal>
- </para>
- </listitem>
- </itemizedlist>
- <para>
- Or use the <command>make</command> targets as described above.
- </para>
- <para>
- Once this done go to
- <ulink url="https://sourceforge.net/project/admin/editpackages.php?group_id=11118">
- https://sourceforge.net/project/admin/editpackages.php?group_id=11118</ulink>,
- making sure you are logged in. Find your target platform in the
- second column, and click <literal>Add Release</literal>. You will
- then need to create a new release for your package, using the format
- of <literal>$VERSION ($CODE_STATUS)</literal>, e.g. <emphasis>&p-version;
- (beta)</emphasis>.
+ and go through the release steps. The upload
+ is done at
+ <ulink url="https://sourceforge.net/projects/ijbswa/upload/">SourceForge</ulink>
+ after logging in.
</para>
<para>
Now just follow the prompts. Be sure to add any appropriate Release
When all (or: most of the) packages have been uploaded and made available,
send an email to the
<ulink url="mailto:privoxy-announce@lists.privoxy.org">announce mailing
- list</ulink>, Subject: "Version X.Y.Z available for download". Be sure to
+ list</ulink>, Subject: "Announcing Privoxy X.Y.Z $CODE_STATUS". Be sure to
include the
<ulink url="https://sourceforge.net/projects/ijbswa/files/">
download location</ulink>, the release notes and the Changelog. Also, post an
SGML files, do:
</para>
<programlisting>
- make dok
+make dok && make dok-tidy
</programlisting>
<para>
That will generate <filename>doc/webserver/user-manual</filename>,
If these are docs in the stable branch, then do:
</para>
<programlisting>
- make webserver
+make webserver
</programlisting>
<para>
This will do the upload to the SourceForge webserver (which is manually
projects / privoxy.git / blobdiff