Re: Packaging GNUstep automatically
Am 26.12.2013 05:12, schrieb Paul Wise:
> You asked about automated packaging, which isn't something we do in
> Debian right now AFAIK.
This is something which should change, IMHO :-)
>> I feared such an opinion. Packagers apparently think in releases only,
>
> That certainly isn't true since packaging generally necessitates
> becoming a software developer who contributes upstream and commits to
> version control systems.
Are these bugs forwarded to the upstream bug tracker? The tracker is here:
https://savannah.gnu.org/bugs/?group=gnustep
While GNUstep has a record of moans against Debians' refusal to accept
Mac OS X like frameworks (binaries, headers, libraries and auxiliary
files in one directory), I think they have also evolved enough now to
live with a strict FHS policy. At least they offer build options to
comply with FHS. Wether this is good for a free implementation of Mac OS
X or not is a different topic.
>> volunteer driven software development no longer does such things.
>
> Personally I think that is a bad idea and is detrimental to the health
> of the Free Software community.
The equitation is simple: resources are limited, so a developer can
either work on maintaining older releases or she can advance the
project. Accordingly, doing release maintenance slows down development.
>> Every commit improves the status
>
> As a gross generalisation; the experience of Debian and other Linux
> distributions says that this isn't true, regressions happen, often.
Yes, they happen, and they're fixed on HEAD just as well.
> Personally I'm glad I live in the world of Debian, copyleft and Free
> Software instead of in the iPhone world where user freedom is frowned
> upon :)
And what stops free software from achieving a similar smooth user
experience? On the user side, Debian packaging is pretty good already,
it rarely takes more than a minute to find the wanted piece of software.
On the developer side I see pretty much the opposite: a process far more
complex than what developers feel capable of dealing with, while iPhone
developers simply drop their binary package somewhere.
>> Which trouble? I see only "needs maintainer" multiple times.
>
> Lets see:
>
> http://packages.qa.debian.org/m/meta-gnustep.html
>
> The metapackage isn't in testing because [...]
Thanks a ton for the list, I'll keep this for later. Undoubtly I can't
fix much if I can't even build a basic package.
Things I've learned so far:
1) Source packages are not to be confused with binary packages. Source
packages typically produce more than one binary package. Source packages
reflect what's in the upstream source code repository. We work with
source packages here.
2) To find out which source package is needed, do a dry run for one of
the binary packages:
PKG_NAME=gnustep-make-doc
apt-get -s source ${PKG_NAME} | tee /tmp/$$
if grep -q "Picking" /tmp/$$; then
PKG_NAME=$(awk '/^Picking/ { print substr($2, 2, length($2) - 2); }'
< /tmp/$$)
fi
rm -f /tmp/$$
3) Packages have to be built locally before uploading.
4) Package builds happen against a previous package, so let's fetch this:
(cd .. && apt-get source ${PKG_NAME})
5) The first step is to grab debian/ from the older package and moving
it to the new bunch of sources.
rm -rf debian
tar -xvzf ../${PKG_NAME}*debian.tar.gz
6) Then add a changelog entry with "dch". Important, because debuild
grabs the version information from here. Also, the version number is
used for sorting packages by age:
. Version
dch -v "${GNUSTEP_MAKE_VERSION}-$(date +%Y%m%d)" -D saucy
"Version" is a file provided by GNUstep, "saucy" is the distribution you
want to build against. An editor will open, add something like "Weekly
snapshot.", save and quit.
7) That done, "quilt" is the tool to maintain the package-side series of
patches in debian/patches. Good tutorial here:
http://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
Do "quilt push" until all patches are applied.
7a) If a patch reports "offset" or "fuzz", also do a "quilt refresh".
This updates the patch to the new sources.
7b) If a patch became obsolete, delete it with "quilt delete -r"
7c) If a patch no longer applies but is still needed, fix it manually by
editing source files, then do a "quilt refresh".
7d) If there's need for an additional patch, edit the sources, then
record the patch with "quilt new <patch name>". Wether an additional
patch is required is found out by building, installing and testing the
package, so you want to return here in case results aren't satisfying.
Note: I see some tools try to apply patches automatically. This might
lead to confusion easily if patches no longer apply cleanly, so I'd
prefer to not automate this.
8) Now it's a good time to change debian/control.in and/or debian/rules.
9) Build a package locally with "debuild ... "
Uhm, here I'm stuck. Some instructions recommend "debuild -d", some
"debuild -i -uc -us", some "debuild -S -sd". All of them fail with the
same error:
$ debuild -S -sd
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of gnustep-make_2.6.6.orig.tar.gz,
gnustep-make_2.6.6.orig.tar.bz2,
gnustep-make_2.6.6.orig.tar.lzma, gnustep-make_2.6.6.orig.tar.xz or
make.orig)
It's a bit unclear to me why it asks for a tar of the _new_ package. Can
you help?
10) Upload the package:
dput ppa:mah-jump-ing/ppa ../${PKG_NAME}*.changes
> I note that the packaging available there is uses an old-style
> debian/rules file instead of the short modern style with dh.
A chance to simplify the process? Do you have one of your many links at
hand on how to do this transition? I think it should happen at 8), right?
Thanks a ton,
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/
Reply to: