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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
