[Pkg-kde-talk] KDE 3.4 package underway

[Christopher Martin]

--nextPart1818658.H6KQEXuP3i
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On March 1, 2005 15:14, Isaac Clerencia wrote:
> Welcome back, Christopher! it's great to have you again with us :), I
> expect you have enjoyed this time.

On March 1, 2005 16:19, Adeodato Sim=F3 wrote:
>   Hi! Glad to see you back. As Isaac said, I hope you enjoyed
>   yourselves and all that stuff. ;-)

Thanks, guys. Rest assured, I had a great time :)

> > 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.

OK, I'll look into doing this.

>   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?

I noticed that huge pile of stuff under ksgmltools2, but haven't looked at=
=20
it...

>   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.

OK.

> > 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).

That's reasonable. We (unless I'm missing something obvious...) just need t=
o=20
figure out how to make CDBS work nicely with uuencoded patches. If the=20
built-in patch system can't do it, we'll have to handle it ourselves in=20
kde.mk.

>   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).

Ah OK. Does anyone know about texinfo? Nothing too awful happened when I=20
removed it, but...

> > > 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?

Yup.

> > >   + 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...

Not at all :) Still, if the first uploads are going to experimental, I'm=20
slightly tempted to yank them and see what happens. It just depends on=20
whether we feel more like playing it safe, or more like neat-freaks making=
=20
a break with the past.

> > 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.

Ah, well if we #include it, then you're right of course - 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?

isaac, do you have that link?

As for your question, I _believe_ it can use gamin even when built against=
=20
fam. This is easy to test, since libgamin0 provides libfam0c102.

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

Sure, wouldn't hurt to ask. Ubuntu switched to gamin as well.

> > >     - 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)
>=20
>   sharutils: see above
>   texinfo: dunno
>   x-g-d: ok, doesn't seem the same situation as x-s-p (can't find an
>          #include)

OK, we can prune that one.

> > >     + use wildcards in *.install =3D> 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.

That's a good point.

> > 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=3D1" (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...)

Yes.

>   Anyway, seems we can do=20
>   the effort for this 'nice-to-have' payoff.

OK. Mind if I remove the debian/stamp-cvs-make stuff then?

> > 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).

isaac: thanks! The only other uploads I can think of that are still=20
needed/would be really nice are: kdenetwork (as above), and kdelibs (post=20
OO.org 1.1.3 in Sarge). We're in pretty good shape otherwise.

Cheers,
Christopher

--nextPart1818658.H6KQEXuP3i
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Christopher Martin <chrsmrtn@freeshell.org>

iD8DBQBCJhW+U+gWW+vtsysRAmNzAJ4pVzVNHWSzOitE6uX9WWWO1Z/YSQCfXK5D
KNraKW7yb/wbdxHcwYnmlPI=
=uN9e
-----END PGP SIGNATURE-----

--nextPart1818658.H6KQEXuP3i--