Debian Kubuntu Pkging Collaboration

Achim Bohnet ach at
Wed Oct 11 01:07:19 BST 2006

On Wednesday 04 October 2006 23:36, Achim Bohnet wrote:
> Hi,
> as promised long time ago in a kubuntu meeting I've
> written a little wiki page, describing how KDE application
> pkgs are managed in Debian by the 'Debian KDE Extras Team'.
> It also tries to explain how Kubuntu developers can
> commit changes themself, saving the time to file a
> bug at or merging again and again on
> syncs from sid.
> Suggestions, fixes (it's a wiki, hint, hint) welcome.

Thx to Mark Purcell, pkg-kde-extras was added to  You can find automaticly build dapper/edgy
svn pkgs at:

More details how it works in the attached e-mail.

> Achim
> -- 
>   To me vi is Zen.  To use vi is to practice zen. Every command is
>   a koan. Profound to the user, unintelligible to the uninitiated.
>   You discover truth everytime you use it.
>                                       -- reddy at

  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at

Mark and the rest of the pkg-kde-extra guys,

Am Montag, den 09.10.2006, 08:57 +1000 schrieb Mark Purcell:
> One of the other teams I work with on alioth (pkg-voip-maintainers) has a 
> buildd environment setup to take the archive from and build 
> for Debian SID, ETCH and SARGE (i386, amd64, powerpc and s390) as well as 
> Ubuntu DAPPER and BREEZY (i386, amd64 and powerpc).

That must be me then. ;)
It's DAPPER and EDGY, not DAPPER and BREEZY no more. And for the sheer
lack of more diskspace right now there will not be any s390 snaps for

Yet, to start, let's have a glimpse of what the buildd does:
1.) take a checkout of $packagename/trunk/ from svn.d.o or whatever is
    coded in the checkout script for a certain distro
    (e.g. .../branches/sarge/ for Debian Sarge backports)
2.) Compare the latest checkout/update svn version  to what was last 
    sucessfully processed and uploaded into the buildd. If the checkout 
    is newer, then run the following steps, otherwise proceed to next
3.) Grab version from debian/changelog and:
     - if dist=UNRELEASED, reduce debian part by 1
     - if dist=experimental/unstable/testing/stable: leave as is
    b) add to this preprocessed version $dist.$svnrevision
[note: this will sooner or later be changed to the new ~$dist.$svn style
as comes with latest dak and dpkg updates. Yet for now the above
    c) grab source through get-orig-source target, if not available. 
       Make sure all files are deleted if they have been faulty or
       plain bad downloads (like 404 webpages).
    d) Run svn-buildpackage to get a source upload. Build-depends are 
       therefore *not* respected. If you think that your package has a
       valid get-orig-source and clean target in debian/rules, yet is
       not updated in the buildd, feel free to ask for more details why 
       the checkout update fails. (Or I shall plain forward you the 
       email with the long checkout chatter.)
4.) Upload to where it's being processed by a 
    regular dinstall (4 times per hour) run into dak. The 
    gpg-signatures are all automagically added by the buildds, no human
    interaction is needed here to speed up the whole process.
5.) Regular dep-wait/building/uploaded etc. for all packs through 
    wanna-build. Stats are most preferably tracked through:
    The email alias can be used for all packs or single packages 
    selected through the bottom input field.
6.) For completed uploads a britney run in done every hour to move all 
    installable packages *per arch* into the public archive
    The according britney outputs can be found through wherever pkg-kde-* does not
    end in -build. 

That gives you sources.list lines like:
deb sid main
deb-src sid main

deb edgy main
deb-src edgy main

and so on. If someone feels that an extra mirror is needed, we can setup
push mirroring easily as we have it for the ekiga-cvs snapshots. Feel
free to mail me with details.

> I have also asked Kilian to provide buildd results and commits through to the 
> pkg-kde-extras lists.

Logs go straight into and so far nowhere else as
sbuild doesn't really support filtering certain packages to mail logs to
different aliases properly. I could open the dak whitelist, yet this
will impose quite some bad SNR to the pkg-kde-extras list. Yet, if this
is really wanted, I'll do it. 

Hope this gets you guys a quick jumpstart on how to use this new archive
as a means to enhance the package overall quality through automagic
porting. Eventually sparc will join the list of arches the next days as
zee finally found its way back into the colo. 

As always, if you got any questions, feel free to mail them, yet as I
don't read pkg-kde-extra, CC me or have Mark forward relevant bits to
me. ;)

Best regards,

More information about the kubuntu-devel mailing list