DebianPackagingTaskTeam

Target completion date:

If you want to participate in this project, add your name to the "Participants" field in the form.

Goals

• Maintain packages for the Debian distribution, for:
  • the core of foswiki
  • foswiki plugins

Required Knowledge

• Experienced Debian users
• Experienced Debian package maintainers
• Maybe Debian Developers
• Other similar profiles for Debian-derivative distributions

Discussion

See Tasks.Item8021 for a discussion on Debian package's maintenance difficulties.

see DebianPackage for details about Sven's fosiki foswiki debian repository with foswiki v1.0.0 and 105 autobuilt extensions from Extensions.

-- OlivierBerger - 09 Jan 2009

I took the liberty to fix some wording.

Adding myself in this task team, as I've started the idea eons ago. Not sure Sven needs any help, but if he does, I'll be glad to help.

-- OlivierRaginel - 09 Jan 2009

I would rename this to PackagingTaskTeam, as the debian part is the most trivial. The hardest is to make sure that Foswiki is security bug free, fixes bugs in a timley manner and that all Extensions are built properly using BuildContrib, and have correct DEPENDANCY files.

while the core Foswiki release package is in our svn, the Extension deb builder just transforms the BuildContrib definitions into debs - and rpms, and so on (using a currently proprietory fosiki set of scripts built over the last 3+ years). I'm working on re-writing these as CPAN modules, but assure you that in reality, the problems and workload is all focussed around the quality of the upstream code (ie, whats uploaded to foswiki.org).

-- SvenDowideit - 09 Jan 2009

I see your point Sven, but still, I think there's a need for a specific collaboration area for discussion of small details relating to technical choices made for the Debian packaging (including maintenance of scripts, etc.), should collaborative maintenance be chosen. Thus, a dedicated communication channel would be better, I think (personnally I prefer mailing-lists than comments in wiki pages for discussion).

But Maybe there's a need for a general packaging task team too, of course.

Also, I suggest that all interested subscribe to debian's ITP ticket : 509864-subscribe@bugs.debian.org

-- OlivierBerger - 12 Jan 2009

I've added myself to the project team as I'm interested in getting .debs out soon and into Debian before the squeeze code freeze. Foswiki is a pretty complex beast to package up, but I've been using my own non-release-grade packages since about twiki2 and havesome experience with the long-term maintenance issues of packaged deployments. There's a lot of complexity I'd like to reduce (separating the binaries from the twikitext and from the configuration logic), and would like to have automated builds and tests running continuously from the Debian packaging repository, whether that's part of Foswiki or separate.

An automated core build for 1.0.x s at http://debmarshal.debian.net/foswiki/ I'd like to expand that to modules and the trunk.

The build is fairly complex right now, with the build script in a different branch of the repository as the source, and tarballs generated out of branch and pulled back as official release source. In my autobuilder, I didn't simplify that, but am building from current repository contents rather than waiting on a release tarball.

Having the packaging for the release branch on the trunk prevents work on trunk packaging, and freezing after release provides nowhere for the now-delayed packaging work. Does anyone see a problem with moving the current 1.0 packaging to the 1.0 release branch and letting trunk packaging live on trunk? That way each autobuilder only needs to check out one copy of the repository and build from that.

-- DrakeDiedrich - 25 Aug 2009

I get the feeling that you and I are working in opposite directions.

http://svn.foswiki.org/branches/Release01x00/core/tools/pkg/ is traditionally where I used to build the release debs from, but I havn't recently kept that up to date (ie, I trialled things in the trunk pkg code, and then pushed them into the release branch).

secondly, I'm intending to build the debs (and separate out the bits) using the foswiki MANIFEST - ie, build one installable package for each include line in http://svn.foswiki.org/branches/Release01x00/core/lib/MANIFEST (which I made happen specifically for packaging).

I guess most of this is because you haven't seen the existing system for building (and um, where's my docco )?

clearly, given you're motivated, we should bash out a more common direction, and then we can work together to make squeeze happen...

I'm pretty weirded out by the assertion tarballs generated out of branch and pulled back as official release source - clearly, those tarballs are not official source packages that can be used for real debian packages - they are only development source files - and I did see a debian mailing list discussion recently on the use thereof..

more to come..

-- SvenDowideit - 25 Aug 2009

I'm concerned that there seems to be a lack of coordination between the members of this team, perhaps a result of there being no identified team lead. DrakeDiedrich seems to be taking a lead on it via foswiki-discuss, however; should Drake be identified as team lead?

Is there an overlap with the ReleaseTaskTeam? How do you guys coordinate?

-- CrawfordCurrie - 09 Dec 2009

Hi, I am also interested on this. Sven, is there a reason why a .deb for 1.0.8 was not released? If it's a matter of manpower, I can help with that since I have at least 3 servers using your Foswiki debian packages.

I've made one for my own use from the packaging in http://svn.foswiki.org/branches/Release01x00/core/tools/pkg with the following changes:

Index: debian/changelog
===================================================================
--- debian/changelog    (revisão 6047)
+++ debian/changelog    (cópia de trabalho)
@@ -1,3 +1,9 @@
+foswiki (1.0.8) unstable; urgency=low
+
+  * New upstream release
+
+ -- Antonio Terceiro <terceiro@softwarelivre.org>  Fri, 15 Jan 2010 17:29:41 -0300
+
 foswiki (1.0.7-3) unstable; urgency=high
 
   * fis up the legacy redirect from /cgi-bin/foswiki
Index: build_deb.sh
===================================================================
--- build_deb.sh        (revisão 6047)
+++ build_deb.sh        (cópia de trabalho)
@@ -1,24 +1,32 @@
 #!/bin/sh
 
+foswiki_version=$(dpkg-parsechangelog | awk '{if ($1=="Version:") print $2 end}')
+if [ -z "$foswiki_version" ]; then
+       echo 'Cannot determine package version. There is something seriously wrong.'
+       exit -1;
+fi
+
+echo "Building Debian package for Foswiki $foswiki_version ..."
+
 if [ -e /tmp/build_deb ]; then
        echo '/tmp/build_deb already exists, please move aside'
        exit -1;
 fi
-if [ ! -e Foswiki-1.0.7.tgz ]; then
-       echo 'need Foswiki-1.0.7.tgz file to build'
+if [ ! -e Foswiki-$foswiki_version.tgz ]; then
+       echo "Need Foswiki-$foswiki_version.tgz file to build"
        exit -1;
 fi
 
 mkdir /tmp/build_deb
 cp -r debian /tmp/build_deb/
-cp Foswiki-1.0.7.tgz /tmp/build_deb/foswiki_1.0.7.orig.tar.gz
+cp Foswiki-$foswiki_version.tgz /tmp/build_deb/foswiki_$foswiki_version.orig.tar.gz
 
 cd /tmp/build_deb
-tar zxvf /tmp/build_deb/foswiki_1.0.7.orig.tar.gz
+tar zxvf /tmp/build_deb/foswiki_$foswiki_version.orig.tar.gz
 
 #add * to allow for -beta, -auto etc
-mv /tmp/build_deb/Foswiki-1.0.7*/ /tmp/build_deb/foswiki-1.0.7/
-cd /tmp/build_deb/foswiki-1.0.7
+mv /tmp/build_deb/Foswiki-$foswiki_version*/ /tmp/build_deb/foswiki-$foswiki_version/
+cd /tmp/build_deb/foswiki-$foswiki_version
 
 mv ../debian .
 

-- AntonioTerceiro - 15 Jan 2010

the reason is really stupidly simple there was a bug found in the first week of 1.0.8's release that we decided should be fixed and a 1.0.9 made very quickly, so I waited for it - and then after a few weeks passed, i forgot. and now, with 1.0.9 coming out this week, I'll make a 1.0.9 release instead.

On the flip side, I'm also hoping that Drake's work will superceed mine - but I guess that won't be for a while.

-- SvenDowideit - 16 Jan 2010

is it also within the scope of this team's goals and responsibilities to prepare debian CPAN packages which are prerequisites for extensions? Tasks.Item2517 points out that KinoSearchContrib needs libkinosearch-perl, libencode-detect-perl. if so, i imagine our process would be to have them in the foswiki debian repository while the process to add them upstream to debian proper progresses.

• KinoSearchContrib dependencies
• MailInContrib dependencies

-- WillNorris - 21 Dec 2009, 18 Mar 2010

how do we deprecate plugins from the debian repository?

http://fosiki.com/Foswiki_debian/pool/main/f/ contains Extensions/Archived.TinyMCEUsabilityUpgradePlugin, which should be moved to the deprecated extensions area. http://fosiki.com/Foswiki_debian/pool/main/f/foswiki-tinymceusabilityupgradeplugin/ (as well as the typoed http://fosiki.com/Foswiki_debian/pool/main/f/foswiki-tinymceusabiltyupgradeplugin/ version) are in the current debian repository.

Tasks.Item8088 describes an old problem with a soon-to-be deprecated plugin. not only do i want to close that bug, i'd like to prevent someone filing a bug again in the future after they've installed the deprecated plugin from the debian repository.

-- WillNorris - 19 Mar 2010

I only use Linux occasionally, an Ubuntu laptop, and don't (want to) know much about it, but I did add lines to some file so it would find more packages to install.

When I saw foswiki there, I thought hey let's try the 'proper' package and installed it that way. I was thrilled to see it appear as one of the wikis on offer to install.

But the big surprise was when I fired up the computer a couple of weeks later. Some utility comes up with a list of programs that have more recent versions to update to, and blow me down with a feather, there were a couple of updates for foswiki!

Thanks guys. Oh sure I can easily install it my own way from the archive, but I was thrilled to see you're putting in the work that's making it be held up on offer and readily available to a casual Debian/Ubuntu user.

-- SueBlake - 22 Mar 2010

In response to the question about deprecating plugins (WillNorris 19 Mar 2010): if the plugins are put in seperate binary packages (aka debs), then later versions of the main foswiki package could conflict with those packages (or certain versions of those packages). That might be a little strong for deprecation, since it will remove the package, but I thought it was worth mentioning. It would be nice to have this in the main Debian archive.

If a plugin is replaced by a different plugin, the package for the first could be turned into a dummy package that depended on the new plugin. Upgrading the data might be challenging in that case.

-- RossBoylan - 27 Apr 2010

I'm interested in using the latest version of Foswiki and find the Fosiki Debian packages very useful. Is there a roadmap planned for the release of newer versions?

-- GavinMcGinney - 01 Feb 2011

This task team seems to be to be abandoned. If you'd like to revive it, please do so and add yourself to the team lead. Thanks for all work done in this team so far.

-- MichaelDaum - 23 May 2014

Commenting is disabled while not logged in