[Pkg-kde-talk] KDE 3.4 package underway

[Adeodato Simó]

* Christopher Martin [Tue, 01 Mar 2005 12:33:20 -0500]:
> Hello,

  Hi! Glad to see you back. As Isaac said, I hope you enjoyed
  yourselves and all that stuff. ;-)

> > arts:
> >   - not merged changes from Christopher
> >     + manpages deletion (plus removing docbook-to-man from B-D)

> I deleted the manpages that were just placeholders. No manpage is better 
> than a fake one, since then the problem is less hidden. Also, fake pages 
> tend to really annoy users. This is bug #292084.

  Yes, I fully agree. I just didn't merge because I felt a little lazy
  about it.

  BTW, I heard something somewhere upstream about KDE 3.4 having added
  lots of manpages. There is ksgmltools2/customization/kde-man.xsl...
  Does somebody know something?

  Also, I have to write a mail about the manpage generation in
  debian/rules, putting that in kde.mk, and how would that affect
  packages that ship non-generated *.1 files.

> >   + the removal of "sharutils, texinfo, xlibs-static-pic" in B-D

> sharutils I removed until we figured out a uu patch method,

  If you mean, 'until there is a uu-encoded patch needing it', I'd
  prefer to have it permanently, rather than add it when needed. I
  believe that the second method will end up in a FTBFS sooner or later
  (because it is easy to forget to add the B-D).

  I intend to write a mail commenting how we manage branch pulls.

> though we're not 
> likely to need one very often. xlibs-static-pic/texinfo was aggressive 
> "let's see what and how things break" pruning.

  I see. I can't speak for texinfo, for x-s-p it's probably safe
  removing except in base, network, graphics and multimedia (see their
  07_xlibs-static-pic.diff patches).

> > kdelibs:

> >  - not merged changes from Christopher
> >    + manpages removal <-- I agree, but I don't understand why he has
> >       removed all *.sgml files and left only the generated *.1 ones

> I was lazy when putting together the initial packages :) Anyway, as with 
> arts, I'd like to remove all the dummy pages.

  Yes, but keeping the non-dummy *.sgml, right?

> >   + build-dependencies:
> >      - remove libdb4.2-dev, libldap2-dev, libpam0g-dev, libxrender-dev

> I wasn't sure whether db, ldap, and pam are needed for kdelibs nowadays. 
> Nothing depends on them, and no obvious configure checks fail without them 
> (IIRC).
  
  Well, if you feel confident...

> As for xrender, libqt3-mt-dev pulls that in.

  Uhm, true, but kstyle.cpp #includes Xrender.h, and as good NMs we know
  that "you must build-depend in everything you #include". :P Now
  seriously, unless there is a stronger reason to remove it, I prefer
  that it stays.

> >     - remove libfam-dev in favour of libgamin-dev --> works?

> Works well here, anyway. A nice bonus is that gamin supports inotify, so 
> we'll gain support for that when it reaches the kernel.

  Aha. I was talking with Isaac about this, and he found a link about
  somebody experiencing problems (hangs) with a gamin-enabled kdelibs.
  OTOH, I thought the libraries were ABI compatible, so: can gamin be
  used when kdelibs has been compiled against fam headers? And
  vice versa? If so, which headers to use?

  Also, perhaps we should find out how does upstream feel about this.

> >     - remove docbook-to-man, sharutils, texinfo, xlibmesa-glu-dev

> Same as above, with xlibmesa-glu-dev pulled in by Qt.

  docbook-to-man: keep (unless we aren't keeping non-dummy *.sgml files)
  sharutils: see above
  texinfo: dunno
  x-g-d: ok, doesn't seem the same situation as x-s-p (can't find an
         #include)

> >     + remove kdelibs-bin depending on python

> My policy was to yank anything I didn't see was needed, then watch in case 
> anything broke. Do we really need this? Anyone?

  I don't know anything about this.

> >     + use wildcards in *.install => calc said it gave problems
> >        sometimes (IIRC)

> Ah, OK. I'd be interesting in learning why/where these problems occurred.

  I don't know what would he refer to, but certainly I wouldn't have
  discovered the libkspell2 soname problem.

> >    - the dependencies of kdelibs4-dev are not synced with
> >       build-dependencies

> I'd started tinkering with this in my packaging, though this hasn't been 
> merged yet (and needs more attention anyway).

  OK.

> 2) Run fakeroot debian/rules buildprep in the debianized source directory. 
> This runs make -f admin/Makefile.common dist, cleans up, and handles 
> patching.

  This was a nice target for you to add, cheers.

> 4) Add "#DPATCHLEVEL=1" (no quotes) as the first line of 99_buildprep.diff.

  Ah, I didn't know symple-patchsys.mk looked for that.

> This way, we keep the .diff.gz nice and clean, with build stuff contained in 
> a patch only. Also, automake/conf are run only once, by the packager, 
> rather than at every build time, which is an extremely bad idea, because it 
> reduces reproducibility (that's also why I took out the 
> debian/stamp-cvs-make stuff from kde.mk - best not to encourage the 
> practice).

  Mmmm, key. My laziness made me accept the .diff.gz bloat (note that
  autothings were called only by the packager, too; it seems that you
  were talking about frob's packages here...). Anyway, seems we can do
  the effort for this 'nice-to-have' payoff.

> As for KDE 3.3 - should we upload kdemultimedia 3.3.2, now that 3.3.1 is in 
> Sarge? kdenetwork could be also use another upload (with the kopete/xmms 
> fix), unless anyone objects.

  Isaac is working on kdemultimedia. As for kdenetwork, I agree that we
  should have a look and do a last round of uploads where necessary
  (e.g., I wouldn't like to upload a new kdeutils).

  Cheers,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
America may be unique in being a country which has leapt from barbarism
to decadence without touching civilization.
                -- John O'Hara