Re: [Gnewsense-dev] Irssi bug #39251

Sam Geeraerts Mon, 12 Oct 2015 14:56:41 -0700

Op Tue, 29 Sep 2015 19:41:34 +0200
schreef stig atle <[email protected]>:


> I have attached the fix, but also as mentioned there is one already in
> the comment section..
> 
> What is the process to get the fix into the source repo?
> (I guess it's one of the devs that takes the patches, tests them, then
> add them?).

From reading your patch I'd say that it works. It'd be great if you can
confirm that you tested the modified binary package yourself. Saves me
some debugging time in the unlikely case that it wouldn't work.

I would also like the patch file to have a DEP-3 header [1] (e.g. [2]).

Ideally, you would produce a debdiff, which is a diff for the whole
debian/ folder. I've attached the relevant wiki pages for in case the
website is out again.

> I'll dig around more for other bugs I can help with now that I know
> the process..

Please do.

[1] http://dep.debian.net/deps/dep3/
[2]
http://bzr.savannah.gnu.org/lh/gnewsense/packages-ucclia/vim/annotate/head:/debian/patches/41046_non_free_reference.patch

Title: Packaging for gNewSense - gNewSense GNU/Linux

Packaging for gNewSense

Introduction

This page describes how to start working on gNewSense packages. That means either modifying Debian packages or creating new packages. The most common reasons for working on packages are

a package is partially non-free and those parts need to be cut out or replaced,
the system should look like gNewSense, not Debian,
we want to include software that is not (yet) in Debian, but which is very useful to free software users.

However, the difference with Debian should be kept minimal, because every change we do we have to maintain ourselves. That includes

tracking upstream (security) updates and importing them quickly,
keeping our changes compatible with imports from upstream,
checking our changes for security problems,
not breaking integration with the rest of the system,
not making other packages unbuildable.

Requirements

You're comfortable with using the command line.
You know how to use a text editor.
You have used apt-get or aptitude and dpkg a few times.

Environment setup

Set some environment variables that are used by the development tools by adding the following lines to your ~/.bashrc:

export DEBEMAIL="[email protected]"
export DEBFULLNAME="Joe Black"
export EDITOR=emacs

You should fill in your own email address, name and editor of choice. Then run

$ . ~/.bashrc

for these to take effect (or start a new terminal). Then install the necessary packages:

$ sudo aptitude install devscripts quilt

Add the upstream distribution to your package sources by creating /etc/apt/sources.list.d/debian.list with these lines (please replace the URLs with a mirror close to you:

deb http://http.us.debian.org/debian/ squeeze main
deb-src http://http.us.debian.org/debian/ squeeze main
deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

To prevent any Debian packages being installed you must configure pinning in /etc/apt/preferences:

Package: *
Pin: release n=squeeze
Pin-Priority: -1

Now update your package indexes:

sudo aptitude update

Next, set the tags lintian should ignore for modified packages. Put the following in $HOME/.lintiantags.

# Lintian tags to be ignored for gNewSense packages that are derived from
# Debian packages.
changelog-should-mention-nmu
source-nmu-has-incorrect-version-number
# original-maintainer
unknown-field-in-dsc
# bzr://
vcs-field-uses-unknown-uri-format

Make a quilt helper script runnable:

sudo cp /usr/share/doc/quilt/examples/dpatch2quilt.sh /usr/local/bin
sudo chmod a+x /usr/local/bin/dpatch2quilt.sh

Lastly, set the default options for quilt in the ~/.quiltrc file:

QUILT_PATCH_OPTS="--unified-reject-files"
QUILT_PATCHES=debian/patches
QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"

Packaging types

New package

If you want to package software that is not yet available in Debian, then follow the guide to build a new package.

Changing a package

If you want to modify an existing package, you first have to know why you want to change it. If the package contains non-free code that needs to be removed, then you have to modify the original source.

On the other hand, if all the sources in the orig archive fall under a free license, but need to be changed anyway, then you follow the package patching tutorial.

CategoryDevelopment CategoryPackaging

Processes/Packaging (last edited 2014-02-01 02:46:45 by FelipeLopez)

Edit (Text)
Comments
Info
Add Link
Attachments
More Actions: Raw Text Print View Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Title: Patching a package - gNewSense GNU/Linux

Patching a package

Make sure you have set up your environment.

Get the source

Download the source package

$ apt-get source my-program

and look for a diff.gz file. If that exists, then you're dealing with a non-native package, else it's a native package. A non-native package is software that comes from outside the distribution (e.g. from GNU). The original source is normally left untouched and changes happen with patch files. A native package comes from the distribution itself (e.g. debian-faq). There is no need to keep changes separate, so the source is edited directly.

Go into the source to start editing.

$ cd my-program-*

For native packages you can skip the next section and just start editing.

Non-native package

Migrate to quilt

Check if the package is using quilt to manage its patches.

grep -i quilt debian/source/format

If that file doesn't exist or the command has no output, then it's not using quilt. If there are no files in debian/patches then you can start using quilt directly (see next section), but first create the file debian/source/format if necessary and make sure it has exactly one line, saying:

3.0 (quilt)

If there are no patches then first try to convert from dpatch format.

dpatch2quilt.sh || echo not dpatch

If the format is not dpatch, then it's cdbs. Check if quilt support is enabled.

grep -E 'quilt.(mk|make)' debian/rules

If there's no output, then replace the following line near the top of debian/rules

include /usr/share/cdbs/1/rules/simple-patchsys.mk

with

include /usr/share/cdbs/1/rules/patchsys-quilt.mk

and add quilt to the list of Build-Depends in debian/control. Now make quilt aware of the existing patches.

quilt push -a

Using quilt

Start a new patch. We don't have a standard for patch names, but it's recommended to include some identification or short description of the problem or solution. In this case, it's the bug report number and a short problem description.

quilt new 654321_non-free_recommendation

and edit the necessary files:

quilt edit main.c

End the patch with a refresh:

quilt refresh

You should now have a .pc and debian/patches directory. If you don't, then check your ~/.quiltrc file and delete ~/.pc and ~/debian/changes if you have them.

See also Raphaël Hertzog's excellent summary about using quilt. Note that Parkes' quilt does not yet support the --dep3 option, so please refer to the DEP-3 format specification. It's good practice to add such a header to your patch.

Update the changelog

Debian provides a tool called dch to help ensure your changelog is valid.

$ dch -i

Briefly describe the change you made, with a reference to the bug report if it solves the problem. Also make sure to edit the version to indicate it has gNewSense changes. For example, if the suggested changelog entry looks like this:

my-package (1.0-2) unstable; urgency=low

  * 

 -- Joe Black <[email protected]>  Sat, 26 Jan 2013 15:27:52 +0100

Then our updated version will be something like:

my-package (1.0-1gnewsense1) parkes; urgency=low

  * Don't recommend non-free software. (Closes #123456)

 -- Joe Black <[email protected]>  Sat, 26 Jan 2013 15:27:52 +0100

Note that we don't have an unstable suite and use the name of the target suite instead. The version string should be identical to the last Debian version except for the gnewsense1 part.

Update the control file

The package should say that it is now maintained by gNewSense. Change the Debian information

...
Maintainer: Dave Smith <[email protected]>
Uploaders: Dave Smith
...
Vcs-Browser: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git
Vcs-Git: git://git.debian.org/git/pkg-xorg/xserver/xorg-server
...

to the values for gNewSense.

...
Maintainer: gNewSense Hackers <[email protected]>
XSBC-Original-Maintainer: Dave Smith <[email protected]>
...
Vcs-Browser: http://bzr.savannah.gnu.org/lh/gnewsense/packages-parkes/my-package/
Vcs-Bzr: bzr://bzr.savannah.gnu.org/gnewsense/packages-parkes/my-package/
...

We always want to have our own Vcs-* fields, even if the file originally doesn't have them. Note that the Uploaders field has been deleted. We currently have no use for it.

README

Create a debian/README.gNewSense file that concisely describes why (and, if it took more than just a patch, how) the package was modified. You can also add any information you deem relevant, but can't fit anywhere else.

The debian/README.gNewSense file must follow the below format (sample):

Changed-From-Debian: A brief description of the change in a single line.
Change-Type: Modified

Longer description of the change is welcome. It can run into multiple lines. This long description can provide more comprehensive info about the details of the change or it might add notes that might be of interest to package wranglers or it might point to other places (like the changelog) where more information can be found.

The fields Changed-From-Debian & Change-Type can occur in any part of the file. The values of these fields can be optionally be formatted in MoinMoin wiki syntax.

Change-Type field can have one of these values — Modified, Added, Removed.

Build the package

First build the source package.

$ debuild -uc -us -S --lintian-opts --suppress-tags-from-file=$HOME/.lintiantags

This will also automatically run lintian to check for mistakes in your package. Also run lintian on the Debian source package

$ lintian my-package_1.0-1.dsc

and fix any warnings and errors that are different. You can get more details about the warnings with the -i option:

$ lintian -i my-package_1.0-1gnewsense1.dsc

If all is well then build the binary packages.

$ sudo aptitude build-dep my-package
$ debuild -uc -us -b

If that fails, fix your patch. If it succeeds, test the binaries by installing and running them.

Submit the patch

You can now reveal your fixed package to your fellow developers and submit it for inclusion in the package repository. Because the whole source package can be rather big, it is better to submit just the differences with the original. You can do this using debdiff.

$ cd ..
$ debdiff my-package_1.0-1.dsc my-package_1.0-1gnewsense1.dsc > my-package.diff

Attach my-package.diff to the bug report or send it to the gnewsense-dev mailing list.