Re: Packaging GNUstep automatically
On Wed, Dec 25, 2013 at 10:01 PM, Markus Hitter wrote:
> 1) Reducing the number of patches coming with the packaging to zero. If
> something doesn't align, upstream should be fixed instead.
As do Debian:
http://www.debian.org/social_contract
> 2) Provide a one-stop script to GNUstep developers which allows them to
> update Debian packages after a release. Something like ./package-release.sh
That is out of scope for Debian.
> 3) Provide automated weekly package updates in this PPA. Similar to
> weekly tarball snapshots, just as a package.
Also out of scope for Debian, unless they plan to put these in Debian
experimental but then it isn't possible to fully automate them because
someone still needs to sign the uploads to Debian.
> There's already an older packaging repo:
>
> git://git.debian.org/pkg-gnustep/gnustep-make.git
> http://git.debian.org/?p=pkg-gnustep/gnustep-make.git
I note that the packaging available there is uses an old-style
debian/rules file instead of the short modern style with dh.
> This older thing provides three packages: gnustep-common, gnustep-make
> and gnustep-make-doc. Copying the debian/ directory from there to
> current sources looks like a step forward, still no chance to actually
> upload these sources. I receive all sorts of errors, from "Can't build,
> because sources have changed" to "control doesn't match" to "no key
> whatever" to "no previous package" (there is no such thing as a
> "previous package") ...
We can't help with errors without you posting the specific error logs.
In general the minimum needed on every new upstream release is listed
here (inspect changes, bump changelog, update copyright at minimum):
http://www.debian.org/doc/manuals/maint-guide/update.en.html#inspectnewupstream
http://www.debian.org/doc/manuals/maint-guide/update.en.html#newupstream
> What would be a good outline to get these weekly updates? Which
> strategy? Is it even wanted to maintain packaging in the upstream repo?
I'd take a step back and ask what the goal is.
Is it QA for developers to be confident in their releases? That might
be better done using an automated CI system like jenkins/buildbot/etc.
Is it so that less technical users can test if their bugs are fixed in
SVN? It would be more forward-thinking to train those users to be more
technical, able to build from source and eventually become
contributors.
PS: the Debian GNUStep packagers appear to be having trouble
maintaining GNUStep, the main metapackage has some release-critical
bugs and isn't in Debian jessie:
http://packages.qa.debian.org/m/meta-gnustep.html
PS: since you appear to be involved upstream, please review our guide
for upstreams.
https://wiki.debian.org/UpstreamGuide
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: