pkg-kde: commit - rev 204 - / www www/docs www/docs/domi
Author: dato-guest
Date: 2004-11-07 13:48:13 -0700 (Sun, 07 Nov 2004)
New Revision: 204
Added:
www/
www/docs/
www/docs/domi/
www/docs/domi/README
www/docs/domi/debian-kde-debug.html
www/docs/domi/debugging-kde-crash.html
www/docs/domi/package_scripts.tar
www/docs/domi/packaging-kde-modules.html
www/docs/domi/working-on-debian-kde-bugs.html
Log:
Created www directory. This will be accesible via http://pkg-kde.alioth.debian.org.
Read alioth:/org/alioth.debian.org/chroot/home/groups/pkg-kde/README for details.
Added: www/docs/domi/README
===================================================================
--- www/docs/domi/README 2004-11-07 18:26:53 UTC (rev 203)
+++ www/docs/domi/README 2004-11-07 20:48:13 UTC (rev 204)
@@ -0,0 +1,2 @@
+These are the some documents by Dominique Devriese.
+See http://lists.debian.org/debian-qt-kde/2004/10/msg00122.html.
Added: www/docs/domi/debian-kde-debug.html
===================================================================
--- www/docs/domi/debian-kde-debug.html 2004-11-07 18:26:53 UTC (rev 203)
+++ www/docs/domi/debian-kde-debug.html 2004-11-07 20:48:13 UTC (rev 204)
@@ -0,0 +1,44 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+ <head>
+ <title>Unofficial Debian KDE Packages with debugging support</title>
+ </head>
+
+ <body>
+ <h1>Unofficial Debian KDE Packages with debugging support</h1>
+
+ <p>I have made available unofficial Debian KDE packages that have
+ been compiled with debugging support. This document should answer
+ any questions about installing and uninstalling them.</p>
+
+ <h2>Installing</h2>
+
+ <p>Installing the packages is as easy as adding the following line to
+ your /etc/apt/sources.list:
+
+ <pre>deb http://www.kde-debian.org/~domi/debian-kde-debug/ unstable main</pre>
+
+ After that, execute the command "apt-get update && apt-get
+ upgrade" as root from a terminal.</p>
+
+ <h2>Uninstalling</h2>
+
+ <p>The packages' version numbers have been chosen such that they are
+ considered newer than the current official Debian KDE packages
+ from unstable, but older than any future versions that will
+ appear. This means that if you wait for the next update of the
+ latter packages, the old debugging packages will be uninstalled
+ automatically. If you want to remove them earlier than that, I
+ recommend removing the debugging packages with apt-get remove,
+ then removing the above line from your sources.list, next updating
+ and reinstalling KDE.</p>
+
+
+ <hr>
+ <address><a href="mailto:devriese@kde.org";>Dominique Devriese</a></address>
+<!-- Created: Tue Dec 30 16:32:35 CET 2003 -->
+<!-- hhmts start -->
+Last modified: Tue Jan 6 17:11:13 CET 2004
+<!-- hhmts end -->
+ </body>
+</html>
Added: www/docs/domi/debugging-kde-crash.html
===================================================================
--- www/docs/domi/debugging-kde-crash.html 2004-11-07 18:26:53 UTC (rev 203)
+++ www/docs/domi/debugging-kde-crash.html 2004-11-07 20:48:13 UTC (rev 204)
@@ -0,0 +1,76 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+ <head>
+ <title>Debugging a KDE crash</title>
+ </head>
+
+ <body>
+ <h1>Debugging a KDE crash</h1>
+
+ <h2>Introduction</h2>
+ <p>In order for the Debian and KDE developers to be able to fix a
+ crash in a KDE program, they need a lot of information about it.
+ This document aims to describe how to get this information.
+ Please send all this information in a bug report, or if asked,
+ reply to the email, with an email containing all this
+ information.</p>
+
+ <h2>Basic information</h2>
+ <p>The first thing to do is to gather basic information about the
+ crash. Exactly what were you doing at the moment of the crash ?
+ Can you reproduce the crash ( i.e. if you do the same thing again,
+ does it crash again ? ). Also you should provide us with
+ information about your system. What version of the Debian KDE
+ packages were you running at the moment of the crash ? Have you
+ perhaps ever compiled separate Qt or KDE versions yourself, that
+ are still installed somewhere ? etc.</p>
+
+ <h2>The Debian KDE debug packages</h2>
+ <p>In order to get more information, you need to install a version
+ of the KDE packages that is compiled with support for debugging.
+ I have written <a href="debian-kde-debug.html">a separate
+ document</a> about how to do this.</p>
+
+ <h2>Getting a backtrace</h2>
+ <p>When a KDE program crashes, most of the time, you see a dialog
+ appear saying what happened and how. There, you can select the
+ tab "backtrace". You'll see that when running the Debian KDE
+ debug packages, it'll contain a lot more useful information than
+ otherwise. Please include the backtrace in your mail. Also, in
+ the crash dialog will be mentioned what kind of "signal" caused
+ the crash. Please mention this in your mail. Possible values for
+ this are "SIGSEGV", "SIGABRT", "SIGALRM" etc.</p>
+
+ <h2>Valgrind: great memory problem debugger</h2>
+ <p>If you are running an i386 machine ( this means, a "normal pc",
+ a "pentium I, II, III, or IV", an AMD "Athlon, Duron" etc., not
+ included are Macintosh machines, and other more exotic devices ),
+ then Valgrind will provide *very* helpful information about the
+ crash. Here is an example of how to get this information ( all
+ this is done from a terminal ).</p>
+
+ <p>Suppose kopete is the application that crashes. Then, you
+ first need to check if the application supports the "--nofork"
+ argument. Try to start the application: "kopete --nofork". If it
+ complains about a wrong argument, then you don't need the
+ "--nofork" argument. If it starts normally, then you do need the
+ argument. In this case, kopete will start normally, meaning that
+ we need the argument.</p>
+
+ <p>Next start the application in valgrind: <pre>valgrind kopete
+ --nofork > /tmp/valgrind-crash-output.txt 2>&1 </pre> Only use the
+ --nofork argument if you need it ( see the above paragraph ), and
+ replace "kopete" by the application that is crashing for
+ you. Then, you need to trigger the crash in the application.
+ Valgrind will record the things that go wrong, and save this data
+ to the file /tmp/valgrind-crash-output.txt. Please attach the
+ generated file /tmp/valgrind-crash-output.txt in your email.</p>
+
+ <hr>
+ <address><a href="mailto:dominique.devriese@student.kuleuven.ac.be";>Dominique Devriese</a></address>
+<!-- Created: Tue Dec 30 16:56:11 CET 2003 -->
+<!-- hhmts start -->
+Last modified: Fri Jan 23 16:48:58 CET 2004
+<!-- hhmts end -->
+ </body>
+</html>
Added: www/docs/domi/package_scripts.tar
===================================================================
(Binary files differ)
Property changes on: www/docs/domi/package_scripts.tar
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: www/docs/domi/packaging-kde-modules.html
===================================================================
--- www/docs/domi/packaging-kde-modules.html 2004-11-07 18:26:53 UTC (rev 203)
+++ www/docs/domi/packaging-kde-modules.html 2004-11-07 20:48:13 UTC (rev 204)
@@ -0,0 +1,244 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+ <head>
+ <title>Packaging KDE modules</title>
+ </head>
+
+ <body>
+ <h1>Packaging KDE modules</h1>
+
+ <h2>Preface</h2>
+
+ <p>There are a lot of special considerations about packaging a KDE
+ module. This page tries to explain the process, and link to other
+ sources for further information.</p>
+
+ <h2>Upstream</h2>
+
+ <p>Relevant upstream links are:</p>
+ <ul>
+ <li>
+ <a href="http://bugs.kde.org";>The KDE BTS</a>: If you're going
+ to package a KDE module, you'll need to forward a lot of bugs
+ here.
+ </li>
+ <li>
+ <a href="mailto:kde-core-devel@kde.org";>The kde-core-devel
+ mailing list</a>: This is the central mailing list for the KDE
+ project. If you have a patch for kdelibs or kdebase that
+ you'd like to see applied, if you have a general question or
+ request, this is where you need to be. You probably also want
+ to follow some lists specific to your package, look <a
+ href="http://lists.kde.org";>here</a> for subscribing to the
+ lists.
+ </li>
+ </ul>
+
+ <h2>Packaging a module</h2>
+
+ <p>There is a complicated procedure for properly packaging a KDE
+ module. I'll try to explain it here, using the source of a little
+ script I wrote to make it easier for me to manage the process.
+ You can find the source of the script <a
+ href="http://www.kalyxo.org/~domi/package-kde-release.sh.txt";>here</a>.
+ </p>
+
+ <p>Note that this is only about the process of creating the
+ package. Read more about what your debian dir should look like in
+ the file /usr/share/doc/kdelibs4-dev/Packaging.txt.gz.</p>
+
+ <p>The script first contains some parameters for its proper functioning:</p>
+ <pre>
+RELEASE="3.2"
+MINOR="2"
+MODULE="kdebindings"
+CVSROOT=":pserver:domi@cvs.kde.org:/home/kde"
+
+version="${RELEASE}.$MINOR"
+releasedir="$MODULE-$version.orig"
+branchdir="$MODULE-$version"
+release_tag=KDE_${RELEASE//./_}_${MINOR}_RELEASE
+branch_tag=KDE_${RELEASE//./_}_BRANCH
+ </pre>
+
+ <p>Adapt the uppercase variables to match your needs. The CVSROOT
+ should reference an account on the KDE upstream CVS server. As a
+ Debian packager, you can normally get such an account easily.
+ Look <a
+ href="http://developer.kde.org/documentation/tutorials/howto/cvsaccount.html";>here</a>
+ for details.</p>
+
+ <pre>
+# export the modules
+echo "Checking out $releasedir..."
+cvs -d$CVSROOT export -r${release_tag} $MODULE > /dev/null
+mv "$MODULE" "$releasedir"
+
+echo "Checking out $branchdir..."
+cvs -d$CVSROOT export -r${branch_tag} $MODULE > /dev/null
+mv "$MODULE" "$branchdir"
+ </pre>
+
+ <p>This checks out two versions of the module. First, the one at
+ the $release_tag ( which looks like KDE_3_2_2_RELEASE ), and
+ secondly, the current version of the $branch_tag branch ( which
+ looks like KDE_3_2_BRANCH ). This works as follows: every time a
+ new major release ( like 3.2 ) is being prepared upstream, a new
+ branch is created, and active development continues on HEAD. For
+ every minor release ( like 3.2.0 ), the BRANCH is tagged at a
+ certain time, a tarball is created, sent to the packagers, and
+ released to the public about a week later. We generally don't use
+ the tarballs they sent us, but check out stuff ourselves. Since
+ the BRANCH version also generally contains some fixes that are not
+ yet present in the release, we include those in the Debian
+ package.</p>
+
+ <pre>
+echo "Creating 001-$MODULE-branch.diff..."
+# remove .cvsignore files
+find "$releasedir" -name '.cvsignore' | xargs rm -f
+find "$branchdir" -name '.cvsignore' | xargs rm -f
+ </pre>
+
+ <p>We don't want .cvsignore files in the source, or lintian/linda
+ will complain.</p>
+
+ <pre>
+# we don't want debian/* stuff diffed in the branch diff
+tempdir=`mktemp -d`
+mv "$releasedir/debian" "$tempdir"
+cp -r "$branchdir/debian" "$releasedir"
+
+# the branch diff
+temp=`tempfile`
+diff -Nrua "$releasedir" "$branchdir" > $temp
+cat $temp | uuencode 001-$MODULE-branch.diff > "$branchdir/debian/patches/001-$MODULE-branch.diff.uu"
+cd "$branchdir"
+# first unapply the branch patch, it will be reapplied by debian/rules
+# configure
+patch -p1 -R < $temp > /dev/null
+cd ../
+rm -f "$temp"
+ </pre>
+
+ <p>Next, we create a diff between the release and branch versions,
+ and put it as the first patch in debian/patches. This makes sure
+ all the fixes from BRANCH are present in the Debian package, but
+ we still get a clean source tar.gz. It is uuencoded, because the
+ debian diff.gz does not handle the binary data, which could
+ otherwise appear in the diff.</p>
+
+ <pre>
+echo "Creating ${MODULE}_${version}.orig.tar.gz..."
+# move back the old debian dir
+rm -rf "$releasedir/debian"
+mv "$tempdir/debian" "$releasedir"
+rm -rf "$tempdir"
+
+# tarball releasedir
+make -C "$releasedir" -f "admin/Makefile.common"
+rm -rf "$releasedir/autom4te.cache"
+tar -czf "${MODULE}_${version}.orig.tar.gz" "$releasedir"
+ </pre>
+
+ <p>The previous creates the source tar.gz. First "make -f
+ admin/Makefile.common" is run, so that the source will
+ contain a configure script, and Makefile.in's. Next it is tarred
+ up under the proper name.</p>
+
+ <pre>
+echo "Preparing $branchdir..."
+# build the package !
+cd "$branchdir"
+
+# this is a hack: we pretend that configure already exists, so that it
+# is not built by the rules script ( by make -f admin/Makefile.common
+# ), and it is subsequently attempted to be run with a lot of args,
+# but it simply ignores them
+echo "echo 'this is a fake configure \!'" > configure
+chmod a+x configure
+make -f debian/rules configure
+rm -f configure-stamp
+rm -f configure
+
+# now that the patches are applied, we can build the Makefile.in's and
+# the configure script
+make -f admin/Makefile.common
+ </pre>
+
+ <p>Next, we want to prepare the package for building. We do this
+ by first applying all the patches ( note that one of the patches
+ should add the AM_MAINTAINER_MODE to the admin/acinclude.m4.in (
+ after AM_INIT_AUTOMAKE ), to prevent unnecessary rebuilds of the
+ Makefile's ), and subsequently, running "make -f
+ admin/Makefile.common", to build the Makefile.in's and the
+ configure script. Note that we used a small hack in order for it
+ to work with a normal debian/rules configure target, without
+ actually doing the configure itself.</p>
+
+ <pre>
+echo "Building..."
+# now that this is all done, we're ready to go !
+debuild
+ </pre>
+
+ <p>Well, the comment says it all, now we're ready to go. debuild
+ should take care of the rest of the process from now on.</p>
+
+ <h2>The KDE/Qt Maintainers Group</h2>
+
+ <p>A lot of KDE modules, and the Qt package are moving toward
+ group maintenance. There is a svn repository at <a
+ href="http://alioth.debian.org";>alioth</a> and <a
+ href="mailto:debian-qt-kde@lists.debian.org";>a mailing list</a>.
+ Some of us regularly lurk on the #debian-kde channel at the
+ freenode IRC network ( it is a user channel, but we also discuss
+ development there ).</p>
+
+ <h2>Various</h2>
+
+ <p>That was it, basically, here are some more various items that
+ should interest you as a maintainer of a KDE module.</p>
+
+ <p>ccache: if you often have to rebuild a KDE package ( and those
+ are known to take a lot of time to build ), you might want to
+ consider using the ccache program. It can take quite a lot of
+ time off your build time, if you regularly need to compile the
+ same source. In order to use it, add the following to the file
+ ~/.devscripts.</p>
+ <pre>
+export DEBUILD_PRESERVE_ENVVARS=CCACHE_DIR
+export DEBUILD_SET_ENVVAR_PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
+ </pre>
+
+ <p>--enable-final: The KDE automake magic has a nice feature
+ called --enable-final. This makes it so that instead of compiling
+ every .cpp file into a .o file, and linking it all together at the
+ end, the make process will first cat all .cpp files together in a
+ _all.cpp file, and compile and link that in one run. This has the
+ effect of speeding up one-time builds, and allowing the compiler
+ more room for optimizations. It does not work for all code
+ though, so you should only use it if you see that it works. It is
+ not officially supported upstream, but they accept patches that
+ fix it. To use it, run "./configure" with the
+ "--enable-final" argument.</p>
+
+ <p>builddir!=srcdir: Something that is useful for more clean
+ builds, is using "builddir!=srcdir". This means that
+ instead of running configure in the source dir itself, you run it
+ in a build tree. The Makefile's will be generated in that tree,
+ and when you run make in it, the generated files will appear there
+ as well. This way, you keep a clean source tree, and you can
+ easily remove it in the debian/rules clean target. This is
+ officially supported upstream, but there are occasionally problems
+ with it in some modules. Most of the kde* packages use this
+ scheme.</p>
+
+ <hr>
+ <address><a
+ href="mailto:dominique.devriese@student.kuleuven.ac.be";>Dominique
+ Devriese</a></address> <!-- Created: Sat Apr 17 10:00:22 CEST 2004
+ --> <!-- hhmts start --> Last modified: Sat Apr 17 10:04:22 CEST
+ 2004 <!-- hhmts end -->
+ </body>
+</html>
Added: www/docs/domi/working-on-debian-kde-bugs.html
===================================================================
--- www/docs/domi/working-on-debian-kde-bugs.html 2004-11-07 18:26:53 UTC (rev 203)
+++ www/docs/domi/working-on-debian-kde-bugs.html 2004-11-07 20:48:13 UTC (rev 204)
@@ -0,0 +1,109 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+ <head>
+ <title>Working on the Debian KDE bugs</title>
+ </head>
+
+ <body>
+ <h1>Working on the Debian KDE bugs</h1>
+
+ <h2>Introduction</h2>
+ <p>The KDE packages in Debian are very high-profile, and very
+ used. A lot of users want to help, and file bug reports against
+ it. Unfortunately, this generates a lot of work for the Debian
+ KDE packagers.</p>
+
+ <p>The reason I'm writing this document is that I am hoping that
+ some of the more advanced users of the Debian KDE packages are
+ also interested in helping in ways beyond simply reporting bugs.
+ This document explains how they can help with the bug
+ handling.</p>
+
+ <h2>The Debian BTS</h2>
+
+ <p>The Debian Bug Tracking System is basically a system where
+ users report problems in the Debian packages, so that the
+ developers know what bugs need fixing. Its most important
+ interfaces are the read-only web interface at bugs.debian.org, and
+ a couple of mail interfaces.</p>
+
+ <p>To get a list of debian bugs, you can best use the
+ bugs.debian.org page, and ask for all bugs belonging to the source
+ package kdebase, kdelibs, kdenetwork, kdemultimedia or meta-kde.
+ These are the most important kde packages, and it's also those who
+ have the highest number of open bug reports.</p>
+
+ <h2>Easy to handle bugs</h2>
+
+ <p>Various kinds of bugs are reported that are not all too
+ difficult to handle.</p>
+
+ <h3>Duplicate bugs</h3>
+
+ <p>Users are supposed to check whether a bug has already been
+ reported before doing it again themselves, but many forget or
+ otherwise fail to do so. If this happens, you should merge the
+ two bugs: send a mail to the control@bugs.debian.org address. The
+ syntax of the mail is described here:
+ http://www.debian.org/Bugs/server-control. Don't forget to use
+ the package command to prevent you from merging the wrong bugs.</p>
+
+ <h3>Upstream bugs</h3>
+
+ <p>Very many bugs in the Debian BTS about the KDE packages are not
+ caused by the Debian packaging, but are problems in KDE itself.
+ If you find such a bug, you should submit a bug report at the KDE
+ BTS ( at http://bugs.kde.org/ ) about the issue. Don't forget to
+ include a link to the Debian bug report in the KDE bug report, so
+ you can easily find it again afterwards. You should then also
+ tell the Debian BTS that you have forwarded the bug upstream. You
+ can again use the control@bugs.debian.org interface for this. Use
+ the tag command to add the "upstream" tag to the bug, and use the
+ "forwarded" command to tell it the url of the upstream bug (
+ e.g. "forwarded 123456 http://bugs.kde.org/show_bug.cgi?id=44803";
+ ). When the bug is fixed upstream, you will receive notification
+ about this from the KDE BTS. You should then send a comment to
+ the Debian bug report, telling them what happened, and tag the bug
+ "fixed-upstream" ( again using the control@bugs.debian.org server
+ ). If an extra question is asked, try to make sure the original
+ submitter can answer it, or do it yourself. If other things
+ happen, do what you think is best, or ask for help on
+ #debian-kde.</p>
+
+ <h3>Invalid bugs</h3>
+
+ <p>Many of the bugs in the Debian BTS about KDE packages have also
+ become invalid over the years. Often it is very useful to ask the
+ original submitter whether the bug is still present in current KDE
+ packages. Often, a user expects the wrong things to happen, often
+ he messed up his own installation. However, you should be careful
+ with this kind of bug. Often, you misinterpret the situation
+ yourself. The gold rule here is to not close a bug unless the
+ submitter acknowledges he was wrong, or until you are very sure
+ that he was indeed wrong, and there is nothing that can be done in
+ the Debian KDE packages to fix the situation.</p>
+
+ <h1>Get going !</h1>
+
+ <p>Now, this is really all you need to know to be able to handle a
+ lot of the bugs in the Debian BTS about KDE packages. You can get
+ started right away. If you find a bug that you don't know how to
+ handle, just ignore it, and try the next one. You can also of
+ course ask people for help on debian-kde@lists.debian.org etc.
+ Please also use your own judgement, try not to mess things up, but
+ it's not all that bad, should it still happen. We're all human,
+ and most things are pretty easily reversible.</p>
+
+ <p>This way, you can provide a valuable contribution to the Open
+ Source KDE community, by helping users with the bugs they see, and
+ by allowing the packagers to concentrate on the real bugs. It may
+ also be a first step to getting further involved in the Open
+ Source world.</p>
+
+ <hr>
+ <address><a
+ href="mailto:dominique.devriese@student.kuleuven.ac.be";>Dominique
+ Devriese</a></address> <!-- Created: Tue Mar 9 21:13:41 CET 2004
+ --> <!-- hhmts start --> <!-- hhmts end -->
+ </body>
+</html>
Reply to: