[Privoxy-devel] Privoxy packaging for Debian

Sun Jan 17 14:50:21 UTC 2021

Hi Fabian!

Sorry for the delay, seems that I should have a more regular look at
this mailing list...

On Fr, 18 Dez 2020, Fabian Keil wrote:

> could you please briefly describe how you currently create
> the Debian packages?

Okay, let's think about what I really do.  This may be really Debian
specific for me, as I build packages that I upload to Debian
(source-only since Debian autobuilds all packages from source
nowadays) as well as packages, that I upload to SourceForge/Privoxy
containing binaries for i386 and amd64 based on the current Debian
stable version.  So here we go (I'll try to use <programlisting> tags,
but avoid <para> to keep this readable here):

Using git-buildpackage we start with a clone of the last Debian version:
<programlisting>
 gbp clone https://salsa.debian.org/debian/privoxy.git
 cd privoxy
</programlisting>
or if the repository is already there
<programlisting>
 cd privoxy
 gbp pull
</programlisting>
Now import the newly released upstream tarball via debian/watch file:
<programlisting>
 gbp import-orig --uscan
</programlisting>

Next update all Debian quilt patches to the new version:
<programlisting>
 while quilt push; do quilt refresh; done
<programlisting>
If some patch is no longer required (because it is already merged
upstream), it can be removed using
<programlisting>
 quilt delete XX_patchname.patch
 git rm debian/patches/XX_patchname.patch
<programlisting>
If the patch needs modification, you can apply, edit and update it with
<programlisting>
 quilt push -f
 quilt edit some_file
 quilt refresh
</programlisting>
until 
<programlisting>
 while quilt push; do quilt refresh; done
</programlisting>
succeeds.  Than you can
<programlisting>
 quilt pop -a
</programlisting>

Now add a new entry to the debian/changelog representing the new
version:
<programlisting>
 dch -v &p-version;-1
</programlisting>
and describe what you did before and don't forget to git commit all
changes.

Now you can build the package on the local machine using
<programlisting>
 gbp buildpackage -us -uc
</programlisting>
You should check for warnings using
<programlisting>
 lintian -iI ../build-area/privoxy_&p-version;-1_amd64.changes
</programlisting>
Maybe rebuild the package in different defined cowbuilder environments
like
<programlisting>
 sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_&p-version;-1.dsc
</programlisting>
And try to run autopackage testing suite on the result:
<programlisting>
 autopkgtest /var/cache/pbuilder/result/privoxy_&p-version;-1_amd64.changes -s -- schroot sid
</programlisting>
Or just push the changes to salsa.debian.org, where a CI pipeline is
defined for the package, that builds and tests it.

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.
Than sign both files:
<programlisting>
 gpg --detach-sign --armor privoxy_&p-version;-1_i386.deb
 gpg --detach-sign --armor privoxy_&p-version;-1_amd64.deb 
</programlisting>
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/

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:
<programlisting>
 sudo apt install build-essential devscripts
 sudo apt-get build-dep privoxy
</programlisting>
After this enter the checked out privoxy git tree and check that all
(new) build dependencies are met:
<programlisting>
 dpkg-checkbuilddeps
</programlisting>
If something is missing, just add it using 
<programlisting>
 sudo apt install foobar
</programlisting>
Now you may update debian/changelog, especially the version number
using
<programlisting>
 dch
</programlisting>
and finally build the package:
<programlisting>
 debuild -us -uc -b
</programlisting>
If everything went okay, you may find the resulting Debian package in
the parent directory.

You may want to clean up the build tree using
<programlisting>
 debian/rules clean
</programlisting>
And maybe repair some artefacts using one or both of the following
commands:
<programlisting>
 git reset --hard
 git clean -fd
</programlisting>

> I would like to update the developer-manual which seems to
> be incomplete at the moment.
> 
> Could you also please commit the changes to the ./debian
> files you made for the 3.0.29 packages?

Did so earlier this day.

> Would it be possible for future releases to commit the
> changes to the ./debian files before the tree is tagged?

That's not that trivial since my current workflow requires that a
upstream tarball is already existing.  Maybe I could try to keep the
debian tree of snapshot more up to date in the future.

> To make GPL compliance more convenient I think it would
> be great if the Debian packages could be easily (re)created
> from a Git checkout which currently doesn't seem to be the case.

I thought about this in the last hours and just wrote about it in the
above "documentation" and just pushed a change to the repository which
makes the current git buildable this way.

> Somewhat related, it's not clear to me why we currently
> don't ship the ./debian files as part of the source tarball.

Since Debian adds the debian dir itself, it usually created some
chaos, if upstream also ships a debian directory, which than has to be
overwritten by Debian and may conflict.  But this seems to be a
historic problem when Debian used old source format (1.0), where the
debian directory was created as a patch, while current 3.0 format
ships debian directory as a tar file and as far as I can see,
dpkg-source -x just deletes debian dir from upstream source on
unpacking and creates a new debian dir from *.debian.tar.xz shipped as
part of the Debian source package.
So it shouldn't be a problem to ship debian dir in upstream privoxy
source tarball nowadays.

> Do you have an opinion about this?
> 
> It looks like the commit that introduced the exclusion
> back in 2002 provided no justification:
> https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=e596ebad5344

I think we can undo this in the meantime.  No idea, who is Moritz :-)

Greetings
Roland

PS: Would it be possible to rename slackware/rc.privoxy.orig to
    slackware/rc.privoxy?  The Debian cleanup mechanisms always delete
    or complain about the file, since .orig is usually some artefact
    of patching...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20210117/bd467de4/attachment.bin>