[Pkg-kde-talk] more KDE 3.4 packaging

[Adeodato Simó]

Hello,

  so, if you're on -commits, you've already seen a bunch of 3.4 related
  stuff. 3.4-rc1 is being released tomorrow or so, and it should be
  fairly usable.

  Daniel, I'm CCing you because I don't know if you're on -talk, and
  some of this stuff may be of interest to you (plus I have a couple
  questions for you below).

  Perhaps I should have mailed earlier, but I thought that the -commits
  messages would serve as a notice that work was being done. I'd very
  much like to have people helping, sorry for not having noticed you
  earlier. As you know, Christopher Martin is away ATM.

  Here are some random notes I'd like to share:

    - I've put the .orig.tar.gz 3.4-rc1 tarballs in 

        costa:/var/lib/gforge/chroot/home/users/dato-guest/kde-3.4.0-rc1

    - Daniel had repackaged arts, kdelibs and kdebase using CDBS, and
      Christopher picked it, so we're switching to CDBS in 3.4.

    - The work is being done in svn://pkg-kde/branches/kde-3.4.0. There
      are some extra subdirs there, which I'll now explain. Most changes
      come from Christopher's people/chrsmrtn/3.4-experimental, only
      that splitted in lots of small commits. The story begins at r477.

    - I'm kind of maintaining a list of things that need to be addressed
      in kde-3.4.0/TODO. If you have insight about any of them
      (specially the first two), please share.

      http://svn.debian.org/wsvn/pkg-kde/branches/kde-3.4.0/TODO?op=file&rev=0&sc=0

    - Daniel, since all of KDE packages are switching to CDBS, I believe
      it makes sense to maintain kde.mk in a central location in the repo.
      Currently, it's on /branches/kde-3.4.0/cdbs/kde.mk, and I was
      thinking of a svn:external to include it in other modules.

      Also, since you're the one that is most used to CDBS, I'd
      appreciate if you assist us/discuss/approve the changes we
      introduce. Ideally, the file should be maintained in a
      conservative way so that it can be used in all modules and there
      are no divergences, right?

      At the moment, it's your copy plus a definition for DEB_PATCHDIRS
      (see next paragraph), a workaround for #296984, and the 'buildprep'
      target (which calls make -f admin/Makefile.common).

    - There is also kde-3.4.0/common-patches, which are patches to the
      admin/ dir that can be shared across modules (since the admin dir
      is identical for all of them). I see it logical to maintain these
      patches in a central location, but I'll appreciate input wrt this.

      The patches that reside there are, of course, 02_autotools_update,
      03_libtool_update, 04_am_maintainer_mode, 05_pedantic-errors, 
      06_automake-1.9 and 07_disable_no_undefined.

      Daniel, would you mind having a look at common-patches/update.sh
      and check that the procedure there for updating 0[23]* is correct?

    - We had pending a mechanism to come up with proper shlib bumps, so
      I've written svn://scripts/check-shlibs. The idea is the same as
      in Daniel's lib-compare.sh, but instead of comparing .debs, it
      compares the nm output of the recently built package (it searches
      the libraries in debian/<each-package>) with the list of symbols
      of the previous shlib bump... which is stored in SVN.

      I don't know if this will sound crazy to you, but I like the idea
      of having the syms (nm output) in svn, check just after building
      and commit updates if necessary. Opinions welcome.
      
  And I think this is all for now.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The pure and simple truth is rarely pure and never simple.
                -- Oscar Wilde