Alejandro Exojo writes: > El Lunes, 4 de Octubre de 2004 09:37, Dominique Devriese escribió: >> Anyway, it's been a real pleasure to work with you all, thanks for >> all your time and valuable help. Thanks all, for your kind words... > By the way, you wrote some HTML documents related to Debian/KDE that > I've been searching some weeks ago, but I didn't found them. There > were in http://www.kalyxo.org/~domi/. One was related to debugging > (it mentioned your debugging packages), and I'm interested in > re-reading again, and maybe posting it in the wiki, so they can be > easily mantained. > If you can send them, or tell me a new URL, it will be great. I'm attaching them. Pierre Habouzit writes: > well it's really a pity you left ... but I may be interested in > maintaining kdebindings ... > I just finisehd my NM process (well I'm waiting for the DAM approval > to be correct). so I'll need sponsoring, but I think I can handle > it. Riku Voipio writes: > Adeodato writes: >> I'm considering adopting the package if nobody more qualified steps >> in. currently, I'm about to prepare 3.3 packages to see if I'm >> ready. if you're thinking about adopting kdebindings > please do. I can still sponsor. I'm glad people are interested in maintaining kdebindings, I hope you and Adeodato can find a good way to cooperate. kdebindings is a very cool package to have in Debian. For the people who are interested in working on the packages, I'm also attaching two scripts I use for automating the packaging of a new upstream release. cheers domi A page about my debian kde packages for user..Title: Unofficial Debian KDE Packages with debugging support
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.
Installing the packages is as easy as adding the following line to your /etc/apt/sources.list:
deb http://www.kde-debian.org/~domi/debian-kde-debug/ unstable mainAfter that, execute the command "apt-get update && apt-get upgrade" as root from a terminal.
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.
A page for debian users who want to file a bug report on a kde crash.Title: Debugging a KDE crash
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.
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.
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 separate document about how to do this.
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.
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 ).
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.
Next start the application in valgrind:
valgrind kopete
--nofork > /tmp/valgrind-crash-output.txt 2>&1 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.
A page for debian kde packages maintainers which explains the process of packaging a kde package.Title: Packaging KDE modules
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.
Relevant upstream links are:
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 here.
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.
The script first contains some parameters for its proper functioning:
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
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 here for details.
# 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"
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.
echo "Creating 001-$MODULE-branch.diff..."
# remove .cvsignore files
find "$releasedir" -name '.cvsignore' | xargs rm -f
find "$branchdir" -name '.cvsignore' | xargs rm -f
We don't want .cvsignore files in the source, or lintian/linda will complain.
# 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"
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.
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"
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.
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
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.
echo "Building..."
# now that this is all done, we're ready to go !
debuild
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.
A lot of KDE modules, and the Qt package are moving toward group maintenance. There is a svn repository at alioth and a mailing list. 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 ).
That was it, basically, here are some more various items that should interest you as a maintainer of a KDE module.
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.
export DEBUILD_PRESERVE_ENVVARS=CCACHE_DIR
export DEBUILD_SET_ENVVAR_PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
--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.
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.
A page for motivated debian users, explaining what they can do to help triage the Debian BTS.Title: Working on the Debian KDE bugs
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.
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.
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.
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.
Various kinds of bugs are reported that are not all too difficult to handle.
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.
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.
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.
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.
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.
A tar file containing the scripts I used for packaging a new upstream KDE release. Normally you first run makeorigtargz.sh and next package-release.sh, but I recommend not using them without having at least read and understood the source.
Attachment:
package_scripts.tar
Description: Unix tar archive