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:[EMAIL PROTECTED]">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:[EMAIL PROTECTED]">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:[EMAIL PROTECTED]">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:[EMAIL PROTECTED]:/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:[email protected]";>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:[EMAIL PROTECTED]">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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [email protected] 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:[EMAIL PROTECTED]">Dominique + Devriese</a></address> <!-- Created: Tue Mar 9 21:13:41 CET 2004 + --> <!-- hhmts start --> <!-- hhmts end --> + </body> +</html>
