important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very
last minute.</p>
<p>So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.</p>
- <p>The following programs are required to follow this process: <tt class="FILENAME">ncftpput</tt> (ncftp),
- <tt class="FILENAME">scp, ssh</tt> (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of make), autoconf,
- cvs.</p>
+ <p>The following programs are required to follow this process: <tt class="FILENAME">ssh</tt>, <tt class=
+ "FILENAME">gmake</tt> (GNU's version of make), autoconf, git, a web browser.</p>
<div class="SECT2">
<h2 class="SECT2"><a name="VERSIONNUMBERS" id="VERSIONNUMBERS">6.1. Version numbers</a></h2>
<p>First you need to determine which version number the release will have. <span class=
<li>
<p>X, the version major, is rarely ever changed. It is increased by one if turning a development branch into
stable substantially changes the functionality, user interface or configuration syntax. Majors 1 and 2 were
- <span class="APPLICATION">Junkbuster</span>, and 3 will be the first stable <span class=
+ <span class="APPLICATION">Junkbuster</span>, and 3 is the first stable <span class=
"APPLICATION">Privoxy</span> release.</p>
</li>
<li>
freeze so that nobody will interfere with last minute changes.</p>
</li>
<li>
- <p>Update the code status (CODE_STATUS="xxx") in configure.in to one of "alpha", "beta" or "stable".</p>
+ <p>Update the code status (CODE_STATUS="xxx") in <tt class="FILENAME">configure.in</tt> to one of "alpha",
+ "beta" or "stable".</p>
</li>
<li>
<p>Rebuild configure and GNUMakefile to make sure the updated values are being used.</p>
<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
- <pre class="PROGRAMLISTING">$ autoheader && autoconf # rebuild configure
-$ ./configure # rebuild GNUmakefile</pre>
+ <pre class="PROGRAMLISTING"> $ autoheader && autoconf # rebuild configure
+ $ ./configure # rebuild GNUmakefile</pre>
</td>
</tr>
</table>
</li>
<li>
<p>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:</p>
+ "for-privoxy-version=x.y.z" minimum version number in <tt class="FILENAME">default.action.master</tt> has
+ been updated:</p>
<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
- <pre class="PROGRAMLISTING">{{settings}}
-#############################################################################
-#MASTER# COMMENT: The minimum Privoxy version:
-for-privoxy-version=3.0.11</pre>
+ <pre class="PROGRAMLISTING"> {{settings}}
+ #############################################################################
+ #MASTER# COMMENT: The minimum Privoxy version:
+ for-privoxy-version=3.0.11</pre>
</td>
</tr>
</table>
<td>
<pre class="PROGRAMLISTING"> $ git tag
# to see the tags
- $ git log [last release tag]..HEAD > /tmp/log
+ $ 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</pre>
<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
- <pre class="PROGRAMLISTING">- Bug fixes:
-- Action file improvements:
-- Filter file improvements:
-- General improvements:
-- Documentation improvements:
-- Build system improvements:
-- Code cleanups:
-- Privoxy-Log-Parser:
-- Privoxy-Regression-Test:</pre>
+ <pre class="PROGRAMLISTING"> - Bug fixes:
+ - Action file improvements:
+ - Filter file improvements:
+ - General improvements:
+ - Documentation improvements:
+ - Build system improvements:
+ - Code cleanups:
+ - Privoxy-Log-Parser:
+ - Privoxy-Regression-Test:</pre>
</td>
</tr>
</table>
<p>All developers should look at the <tt class="FILENAME">ChangeLog</tt> and make sure noteworthy changes are
referenced.</p>
</li>
+ <li>
+ <p>Update the announcement at <tt class="FILENAME">doc/webserver/announce.txt</tt>.</p>
+ </li>
<li>
<p>All documentation should be rebuilt:</p>
<table border="0" bgcolor="#E0E0E0" width="90%">
is version sensitive, so that the user will get appropriate help for his/her release. So with each release a
fresh version should be uploaded to the webserver (this is in addition to the main <i class="CITETITLE">User
Manual</i> link from the main page since we need to keep manuals for various versions available). The CGI
- pages will link to something like <tt class="LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. 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.</p>
+ pages will link to something like <tt class="LITERAL">https://www.privoxy.org/$(VERSION)/user-manual/</tt>.
+ This needs to be updated for each new release and is done with the <span class="QUOTE">"webserver"</span>
+ target.</p>
</li>
<li>
- <p>Tag all files in Git with the version number with <span class="QUOTE">"<b class="COMMAND">git tag
+ <p>Tag all files in Git with the version number with <span class="QUOTE">"<b class="COMMAND">git tag -s
v_X_Y_Z</b>"</span>. Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.</p>
</li>
+ <li>
+ <p>Push the tag to the remote with <span class="QUOTE">"<b class="COMMAND">git push origin
+ v_X_Y_Z</b>"</span>.</p>
+ </li>
<li>
<p>On the webserver, copy the user manual to a new top-level directory called <tt class=
"FILENAME">X.Y.Z</tt>. This ensures that help links from the CGI pages, which have the version as a prefix,
</table>
<p>Also suggested: <tt class="FILENAME">Developer Manual</tt> (doc/webserver/developer-manual) and
<tt class="FILENAME">ChangeLog</tt> (top-level directory). <tt class="FILENAME">FAQ</tt> and the manuals
- are HTML docs. There are also text versions in <tt class="FILENAME">doc/text/</tt> which could conceivably
- also be included.</p>
+ are HTML docs.</p>
<p>The documentation has been designed such that the manuals are linked to each other from parallel
directories, and should be packaged that way. <tt class="FILENAME">privoxy-index.html</tt> can also be
included and can serve as a focal point for docs and other links of interest (and possibly renamed to
should be left in tact as well.</p>
</li>
<li>
- <p>Other configuration files (<tt class="FILENAME">default.action</tt> and <tt class=
- "FILENAME">default.filter</tt>) 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 likely to
- change between releases and contain important new features and bug fixes.</p>
+ <p>Other configuration files (<tt class="FILENAME">default.action</tt>, <tt class=
+ "FILENAME">regression-tests.action</tt> and <tt class="FILENAME">default.filter</tt>) 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 likely to change between releases and contain important new
+ features and bug fixes.</p>
</li>
<li>
<p>Please check platform specific notes in this doc, if you haven't done <span class=
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id="NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>
<p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
- into an empty directory</i></span>. (See "Building and releasing packages" above). Then run:</p>
+ into an empty directory</i></span>. (See "Building and releasing packages" above). Then run from that
+ directory:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> autoheader && autoconf && ./configure</pre>
</td>
</tr>
</table>
</td>
</tr>
</table>
- <p>To upload the package to Sourceforge, simply issue</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id="NEWRELEASE-WINDOWS">6.3.3. Windows</a></h3>
+ <p>Note that the docbook generated files might need some hand editing, so the Windows build makefile does not
+ rebuild the docs.</p>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
+ <p>Check that you have the current versions of the <a href=
+ "https://sourceforge.net/projects/nsis/files/NSIS%203/" target="_top">NSIS installer</a>, <a href=
+ "https://ftp.pcre.org/pub/pcre/" target="_top">PCRE library</a>, <a href="https://tls.mbed.org/download"
+ target="_top">MBED TLS library</a>, <a href="https://github.com/google/brotli/releases" target="_top">Brotli
+ library</a>, and that the <span class="emphasis"><i class="EMPHASIS">MAKENSIS</i></span> evar in <tt class=
+ "FILENAME">windows/GNUMakefile</tt> points to the NSIS installer program. (See the <a href=
+ "../user-manual/installation.html#WINBUILD-CYGWIN" target="_top"><span class="emphasis"><i class=
+ "EMPHASIS">Building from Source / Windows</i></span></a> section of the User Manual for details.)</p>
+ <p>Then you can build the package. This is fully automated, and is controlled by <tt class=
+ "FILENAME">windows/GNUmakefile</tt>. All you need to do is:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> cd windows
+ make</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Now you can manually rename <tt class="FILENAME">privoxy_setup.exe</tt> to <tt class=
+ "FILENAME">privoxy_setup_X.Y.Z.exe</tt>, and the <tt class="FILENAME">build</tt> directory to <tt class=
+ "FILENAME">privoxy_X.Y.Z</tt>. Create a .zip file of the newly renamed <tt class="FILENAME">privoxy_X.Y.Z</tt>
+ directory, GPG sign the installer and zip file,</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> make tarball-upload</pre>
+ <pre class="PROGRAMLISTING"> gpg --armor --detach --sign <tt class=
+ "FILENAME">privoxy_setup_X.Y.Z.exe</tt>
+ gpg --armor --detach --sign <tt class="FILENAME">privoxy_X.Y.Z.zip</tt></pre>
</td>
</tr>
</table>
- <p>Go to the displayed URL and release the file publicly on Sourceforge. For the change log field, use the
- relevant section of the <tt class="FILENAME">ChangeLog</tt> file.</p>
+ <p>and upload the files to SourceForge.</p>
+ <p>When releasing the package on SourceForge, use the release notes and Change Log from the source tarball
+ package.</p>
</div>
<div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-RPM" id="NEWRELEASE-RPM">6.3.3. SuSE, Conectiva or Red Hat RPM</a></h3>
- <p>In following text, replace <tt class="REPLACEABLE"><i>dist</i></tt> with either <span class=
- "QUOTE">"rh"</span> for Red Hat or <span class="QUOTE">"suse"</span> for SuSE.</p>
- <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
- into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
- <p>As the only exception to not changing anything after export from Git, now examine the file <tt class=
- "FILENAME">privoxy-</tt><tt class="REPLACEABLE"><i>dist</i></tt><tt class="FILENAME">.spec</tt> 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 <tt class=
- "REPLACEABLE"><i>dist</i></tt> which is built from version X.Y.Z. Check the <a href=
- "https://sourceforge.net/project/showfiles.php?group_id=11118" target="_top">file list</a> if unsure. Else, it
- must be set to the highest already available RPM release number for that version plus one.</p>
- <p>Then run:</p>
+ <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id="NEWRELEASE-DEBIAN">6.3.4. Debian</a></h3>
+ <p>Using git-buildpackage we start with a clone of the last Debian version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> gbp clone https://salsa.debian.org/debian/privoxy.git
+ cd privoxy</pre>
</td>
</tr>
</table>
- <p>Then do</p>
+ <p>or if the repository is already there</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> make <tt class="REPLACEABLE"><i>dist</i></tt>-dist</pre>
+ <pre class="PROGRAMLISTING"> cd privoxy
+ gbp pull</pre>
</td>
</tr>
</table>
- <p>To upload the package to Sourceforge, simply issue</p>
+ <p>Now import the newly released upstream tarball via debian/watch file:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> make <tt class="REPLACEABLE"><i>dist</i></tt>-upload <tt class=
- "REPLACEABLE"><i>rpm_packagerev</i></tt></pre>
+ <pre class="PROGRAMLISTING"> gbp import-orig --uscan</pre>
</td>
</tr>
</table>
- <p>where <tt class="REPLACEABLE"><i>rpm_packagerev</i></tt> 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.</p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-SOLARIS" id="NEWRELEASE-SOLARIS">6.3.4. Solaris</a></h3>
- <p>Login to Sourceforge's compilefarm via ssh:</p>
+ <p>Next update all Debian quilt patches to the new version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> ssh cf.sourceforge.net</pre>
+ <pre class="PROGRAMLISTING"> while quilt push; do quilt refresh; done</pre>
</td>
</tr>
</table>
- <p>Choose the right operating system (not the Debian one). When logged in, <span class="emphasis"><i class=
- "EMPHASIS">make sure that you have freshly exported the right version into an empty directory</i></span>. (See
- "Building and releasing packages" above). Then run:</p>
+ <p>If some patch is no longer required (because it is already merged upstream), it can be removed using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> quilt delete XX_patchname.patch
+ git rm debian/patches/XX_patchname.patch</pre>
</td>
</tr>
</table>
- <p>Then run</p>
+ <p>If the patch needs modification, you can apply, edit and update it with</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> gmake solaris-dist</pre>
+ <pre class="PROGRAMLISTING"> quilt push -f
+ quilt edit some_file
+ quilt refresh</pre>
</td>
</tr>
</table>
- <p>which creates a gzip'ed tar archive. Sadly, you cannot use <b class="COMMAND">make solaris-upload</b> 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.</p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id="NEWRELEASE-WINDOWS">6.3.5. Windows</a></h3>
- <p>Note that the docbook generated files might need some hand editing, so the Windows build makefile does not
- rebuild the docs.</p>
- <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
- into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
- <p>Then you can build the package. This is fully automated, and is controlled by <tt class=
- "FILENAME">windows/GNUmakefile</tt>. All you need to do is:</p>
+ <p>until</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd windows
- make</pre>
+ <pre class="PROGRAMLISTING"> while quilt push; do quilt refresh; done</pre>
</td>
</tr>
</table>
- <p>Now you can manually rename <tt class="FILENAME">privoxy_setup.exe</tt> to <tt class=
- "FILENAME">privoxy_setup_X.Y.Z.exe</tt>, and the <tt class="FILENAME">build</tt> directory to <tt class=
- "FILENAME">privoxy_X.Y.Z</tt>. Create a .zip file of the newly renamed <tt class="FILENAME">privoxy_X.Y.Z</tt>
- directory, GPG sign the installer and zip file,</p>
+ <p>succeeds. Then you can</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> $ gpg --armor --detach --sign <tt class=
- "FILENAME">privoxy_setup_X.Y.Z.exe</tt>
- $ gpg --armor --detach --sign <tt class="FILENAME">privoxy_X.Y.Z.zip</tt></pre>
+ <pre class="PROGRAMLISTING"> quilt pop -a</pre>
</td>
</tr>
</table>
- <p>and upload the files to SourceForge.</p>
- <p>When releasing the package on SourceForge, use the release notes and Change Log from the source tarball
- package.</p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id="NEWRELEASE-DEBIAN">6.3.6. Debian</a></h3>
- <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
- into an empty directory</i></span>. (See "Building and releasing packages" above). Then add a log entry to
- <tt class="FILENAME">debian/changelog</tt>, if it is not already there, for example by running:</p>
+ <p>Now add a new entry to the debian/changelog representing the new version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> debchange -v 3.0.29-UNRELEASED-1 "New upstream version"</pre>
+ <pre class="PROGRAMLISTING"> dch -v 3.0.34-1</pre>
</td>
</tr>
</table>
- <p>Then, run:</p>
+ <p>and describe what you did before and don't forget to git commit all changes.</p>
+ <p>Now you can build the package on the local machine using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> dpkg-buildpackage -rfakeroot -us -uc -b</pre>
+ <pre class="PROGRAMLISTING"> gbp buildpackage -us -uc</pre>
</td>
</tr>
</table>
- <p>This will create <tt class="FILENAME">../privoxy_3.0.29-UNRELEASED-1_i386.deb</tt> which can be uploaded. To
- upload the package to Sourceforge, simply issue</p>
+ <p>You should check for warnings using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> make debian-upload</pre>
+ <pre class="PROGRAMLISTING"> lintian -iI ../build-area/privoxy_3.0.34-1_amd64.changes</pre>
</td>
</tr>
</table>
- </div>
- <div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id="NEWRELEASE-MACOSX">6.3.7. Mac OS X</a></h3>
- <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
- into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
- <p>There are three modules available in the Git repository for use on Mac OS X, though technically only two of
- them generate a release (the other can be used to install from source).</p>
+ <p>Maybe rebuild the package in different defined cowbuilder environments like</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class=
+ "PROGRAMLISTING"> sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_3.0.34-1.dsc</pre>
+ </td>
+ </tr>
+ </table>
+ <p>And try to run autopackage testing suite on the result:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class=
+ "PROGRAMLISTING"> autopkgtest /var/cache/pbuilder/result/privoxy_3.0.34-1_amd64.changes -s -- schroot sid</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Or just push the changes to salsa.debian.org, where a CI pipeline is defined for the package, that builds
+ and tests it.</p>
+ <p>If everything is okay, run cowbuilder with i386 and amd64 environments for current Debian stable release and
+ build privoxy_3.0.34-1_i386.deb and privoxy_3.0.34-1_amd64.deb. Then sign both files:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> gpg --detach-sign --armor privoxy_3.0.34-1_i386.deb
+ gpg --detach-sign --armor privoxy_3.0.34-1_amd64.deb</pre>
+ </td>
+ </tr>
+ </table>
+ <p>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/</p>
<div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-OSXPACKAGEBUILDER-MODULE" id="OS-X-OSXPACKAGEBUILDER-MODULE">6.3.7.1.
- OSXPackageBuilder module</a></h4>
- <p>The OSXPackageBuilder module generates 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:</p>
+ <h4 class="SECT4"><a name="SNAPSHOT-DEBIAN" id="SNAPSHOT-DEBIAN">6.3.4.1. Debian GIT Snapshot</a></h4>
+ <p>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:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class=
- "PROGRAMLISTING"> cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder</pre>
+ <pre class="PROGRAMLISTING"> sudo apt install build-essential devscripts
+ sudo apt-get build-dep privoxy</pre>
</td>
</tr>
</table>
- <p>The module contains complete instructions on its usage in the file <tt class="FILENAME">OS X Package
- Builder HOWTO.txt</tt>.</p>
- <p>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.</p>
- </div>
- <div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-OSXSETUP-MODULE" id="OS-X-OSXSETUP-MODULE">6.3.7.2. osxsetup module
- (DEPRECATED)</a></h4>
- <p><span class="emphasis"><i class="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.</i></span></p>
- <p>Check out the module from Git as follows into a folder parallel to the exported privoxy source:</p>
+ <p>After this enter the checked out privoxy git tree and check that all (new) build dependencies are met:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class=
- "PROGRAMLISTING"> cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup</pre>
+ <pre class="PROGRAMLISTING"> dpkg-checkbuilddeps</pre>
</td>
</tr>
</table>
- <p>Then run:</p>
+ <p>If something is missing, just add it using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd osxsetup
- build</pre>
+ <pre class="PROGRAMLISTING"> sudo apt install foobar</pre>
</td>
</tr>
</table>
- <p>This will run <tt class="FILENAME">autoheader</tt>, <tt class="FILENAME">autoconf</tt> and <tt class=
- "FILENAME">configure</tt> as well as <tt class="FILENAME">make</tt>. Finally, it will copy over the necessary
- files to the ./osxsetup/files directory for further processing by <tt class="FILENAME">PackageMaker</tt>.</p>
- <p>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:</p>
+ <p>Now you may update debian/changelog, especially the version number using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg</pre>
+ <pre class="PROGRAMLISTING"> dch</pre>
</td>
</tr>
</table>
- <p>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.</p>
- </div>
- <div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-MACSETUP-MODULE" id="OS-X-MACSETUP-MODULE">6.3.7.3. macsetup module</a></h4>
- <p>The macsetup module is ideal if you wish to build and install Privoxy from source on a single machine.</p>
- <p>Check out the module from Git as follows into a folder parallel to the exported privoxy source:</p>
+ <p>and finally build the package:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class=
- "PROGRAMLISTING"> cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup</pre>
+ <pre class="PROGRAMLISTING"> debuild -us -uc -b</pre>
+ </td>
+ </tr>
+ </table>
+ <p>If everything went okay, you may find the resulting Debian package in the parent directory.</p>
+ <p>You may want to clean up the build tree using</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> debian/rules clean</pre>
+ </td>
+ </tr>
+ </table>
+ <p>And maybe repair some artefacts using one or both of the following commands:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> git reset --hard
+ git clean -fd</pre>
</td>
</tr>
</table>
- <p>The module contains complete instructions on its usage in its <tt class="FILENAME">README</tt> file. The
- end result will be the exported version of Privoxy installed on the build machine.</p>
</div>
</div>
<div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id="NEWRELEASE-FREEBSD">6.3.8. FreeBSD</a></h3>
+ <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id="NEWRELEASE-MACOSX">6.3.5. macOS / OS X</a></h3>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
+ <p>The OSXPackageBuilder module generates 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:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> git clone ssh://git@git.privoxy.org:23/git/OSXPackageBuilder.git</pre>
+ </td>
+ </tr>
+ </table>
+ <p>The module contains complete instructions on its usage in the file <tt class="FILENAME">OS X Package Builder
+ HOWTO.txt</tt>.</p>
+ <p>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.</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id="NEWRELEASE-FREEBSD">6.3.6. FreeBSD</a></h3>
<p>Update the www/privoxy port and submit a diff upstream. For details see the <a href=
"https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/" target="_top">FreeBSD Porter's
Handbook</a>.</p>
</div>
<div class="SECT2">
<h2 class="SECT2"><a name="RELEASING" id="RELEASING">6.4. Uploading and Releasing Your Package</a></h2>
- <p>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:</p>
- <ul>
- <li>
- <p>Upload to: <a href="ftp://upload.sourceforge.net/incoming" target=
- "_top">ftp://upload.sourceforge.net/incoming</a></p>
- </li>
- <li>
- <p>user: <tt class="LITERAL">anonymous</tt></p>
- </li>
- <li>
- <p>password: <tt class="LITERAL">ijbswa-developers@lists.sourceforge.net</tt></p>
- </li>
- </ul>
- <p>Or use the <b class="COMMAND">make</b> targets as described above.</p>
- <p>Once this done go to <a href="https://sourceforge.net/project/admin/editpackages.php?group_id=11118" target=
- "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>, making sure you are logged in.
- Find your target platform in the second column, and click <tt class="LITERAL">Add Release</tt>. You will then
- need to create a new release for your package, using the format of <tt class="LITERAL">$VERSION
- ($CODE_STATUS)</tt>, e.g. <span class="emphasis"><i class="EMPHASIS">3.0.29 (beta)</i></span>.</p>
+ <p>After the package is ready, it is time to upload it and go through the release steps. The upload is done at
+ <a href="https://sourceforge.net/projects/ijbswa/upload/" target="_top">SourceForge</a> after logging in.</p>
<p>Now just follow the prompts. Be sure to add any appropriate Release notes. You should see your freshly
uploaded packages in <span class="QUOTE">"Step 2. Add Files To This Release"</span>. Check the appropriate
box(es). Remember at each step to hit the <span class="QUOTE">"Refresh/Submit"</span> buttons! You should now see
<div class="SECT2">
<h2 class="SECT2"><a name="AFTERRELEASE" id="AFTERRELEASE">6.5. After the Release</a></h2>
<p>When all (or: most of the) packages have been uploaded and made available, send an email to the <a href=
- "mailto:privoxy-announce@lists.privoxy.org" target="_top">announce mailing list</a>, Subject: "Version X.Y.Z
- available for download". Be sure to include the <a href=
- "https://sourceforge.net/project/showfiles.php?group_id=11118" target="_top">download location</a>, the release
- notes and the Changelog. Also, post an updated News item on the project page Sourceforge, and update the Home
- page and docs linked from the Home page (see below). Other news sites and release oriented sites, such as
- Freshmeat, should also be notified.</p>
+ "mailto:privoxy-announce@lists.privoxy.org" target="_top">announce mailing list</a>, Subject: "Announcing Privoxy
+ X.Y.Z $CODE_STATUS". Be sure to include the <a href="https://sourceforge.net/projects/ijbswa/files/" target=
+ "_top">download location</a>, the release notes and the Changelog. Also, post an updated News item on the project
+ page Sourceforge, and update the Home page and docs linked from the Home page (see below). Other news sites and
+ release oriented sites, such as Freshmeat, should also be notified.</p>
<p>Then update the source code for the next version to be released:</p>
<ul>
<li>
projects / privoxy.git / blobdiff