pkg kde talk - Mar 2005 - KDE 3.4 package underway

--nextPart2944326.8YQxdveG7W
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I''m back now, and see that many people are doing lots of great work on
the=20
3.4 packages. I''d like to comment on the TODO:
> 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=20
than a fake one, since then the problem is less hidden. Also, fake pages=20
tend to really annoy users. This is bug #292084.
>   + the removal of "sharutils, texinfo, xlibs-static-pic" in B-D
sharutils I removed until we figured out a uu patch method, though
we''re not=20
likely to need one very often. xlibs-static-pic/texinfo was aggressive=20
"let''s see what and how things break" pruning.
> kdelibs:
>=20
>  - 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=20
arts, I''d like to remove all the dummy pages.
>   + 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.=20
Nothing depends on them, and no obvious configure checks fail without them=20
(IIRC). As for xrender, libqt3-mt-dev pulls that in.
>     - remove libfam-dev in favour of libgamin-dev --> works?
Works well here, anyway. A nice bonus is that gamin supports inotify, so=20
we''ll gain support for that when it reaches the kernel.
>     - remove docbook-to-man, sharutils, texinfo, xlibmesa-glu-dev
Same as above, with xlibmesa-glu-dev pulled in by Qt.
>     + remove kdelibs-bin depending on python
My policy was to yank anything I didn''t see was needed, then watch in
case=20
anything broke. Do we really need this? Anyone?
>     + 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.
>    - 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=20
merged yet (and needs more attention anyway).

=2D--

I''d also like to explain how I''d been building my preliminary
KDE 3.4=20
packages, and why I think it''s a nice way to do things:

1) Have two unpacked source directories: foo-1.2.3, foo-1.2.3.orig. One=20
contains a debian subdirectory, one does not.

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

3) Move the debian dir out of the source directory.

3) diff -Nrua foo-1.2.3.orig foo-1.2.3 > 99_buildprep.diff

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

5) Move 99_buildprep.diff to debian/patches, rm -rf foo-1.2.3, and move the=20
debian directory into foo-1.2.3.orig, which is then renamed foo-1.2.3.

6) cd foo-1.2.3, build package.

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

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

Cheers,
Christopher

--nextPart2944326.8YQxdveG7W
Content-Type: application/pgp-signature

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

iD8DBQBCJKdsU+gWW+vtsysRAhznAJ9kBMuT5Ym+owvKWzKiUysX+2ZgGwCgp3Me
tGoljl0211yWPTTa5+D37vY=WiC4
-----END PGP SIGNATURE-----

--nextPart2944326.8YQxdveG7W--

--nextPart1478254.q05Io6EPen
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday, 1 de March de 2005 18:33, Christopher Martin
wrote:
> Hello,
Welcome back, Christopher! it''s great to have you again with us :), I
expect=20
you have enjoyed this time.

Best regards
=2D-=20
Isaac Clerencia=C2=A0<isaac@warp.es>

Warp Networks =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.warp.es
Mar=C3=ADa de Luna 11, 50018 Zaragoza, Spain

--nextPart1478254.q05Io6EPen
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Signed by Isaac Clerencia <isaac@warp.es>

iD8DBQBCJM0tQET2GFTmct4RArufAJ4tKmRszRuI7HrL/nRWToEbqgmU4wCgjRsA
UqemKBR5i6lrhOEKhIpPZuQ=Hq+5
-----END PGP SIGNATURE-----

--nextPart1478254.q05Io6EPen--

* 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

--nextPart1579032.x56mFTIyz9
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Mar 1 Mars 2005 18:33, Christopher Martin a =E9crit :
> 1) Have two unpacked source directories: foo-1.2.3, foo-1.2.3.orig.
> One contains a debian subdirectory, one does not.
>
> 2) Run fakeroot debian/rules buildprep in the debianized source
> directory. This runs make -f admin/Makefile.common dist, cleans up,
> and handles patching.
>
> 3) Move the debian dir out of the source directory.
>
> 3) diff -Nrua foo-1.2.3.orig foo-1.2.3 > 99_buildprep.diff
>
> 4) Add "#DPATCHLEVEL=3D1" (no quotes) as the first line of
> 99_buildprep.diff.

2/3 things :

IIUC the 4) it''s a pragma that helps simple patchsys to discover the=20
patchlevel it has to use  ... but AFAIK, simple patchsys tries -p0 -p1=20
and -p2 alone, so it should work out from the box.


moreover, to have the same thing as what you do to build your=20
99.....patch, you can build the package, and then extract from=20
the .diff.gz the parts that are not related to debian/ files ;)

but honestly, I don''t really see the point in making it a patch in=20
debian/patches since is won''t *really* clean the .diff.gz. It will
only=20
make it a bit worse : it will be the same as before, with 2 lines=20
added, and a big column of ''+'' ;)
=2D-=20
=B7O=B7  Pierre Habouzit
=B7=B7O
OOO                                                http://www.madism.org

--nextPart1579032.x56mFTIyz9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCJQU6vGr7W6HudhwRAsUmAJ9TQ1czy/G3kPnw9Wn52dlWTImN2gCcDPhW
M6huy7vuuym1IarvBLXSCDY=NDJc
-----END PGP SIGNATURE-----

--nextPart1579032.x56mFTIyz9--

--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 to=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--

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

On March 1, 2005 19:13, Pierre Habouzit wrote:
> Le Mar 1 Mars 2005 18:33, Christopher Martin a =E9crit :
> > 1) Have two unpacked source directories: foo-1.2.3, foo-1.2.3.orig.
> > One contains a debian subdirectory, one does not.
> >
> > 2) Run fakeroot debian/rules buildprep in the debianized source
> > directory. This runs make -f admin/Makefile.common dist, cleans up,
> > and handles patching.
> >
> > 3) Move the debian dir out of the source directory.
> >
> > 3) diff -Nrua foo-1.2.3.orig foo-1.2.3 > 99_buildprep.diff
> >
> > 4) Add "#DPATCHLEVEL=3D1" (no quotes) as the first line of
> > 99_buildprep.diff.
>
> 2/3 things :
>
> IIUC the 4) it''s a pragma that helps simple patchsys to discover
the
> patchlevel it has to use  ... but AFAIK, simple patchsys tries -p0 -p1
> and -p2 alone, so it should work out from the box.
The RC1 tarballs dato made available have Makefile.in files provided. I=20
don''t know if dato created them, or whether he just obtained them this
way.=20
Anyway, we patch them, and everything is fine. If, however, you take a CVS=20
checkout, then these files are generated only when make -f=20
admin/Makefile.common dist is run. The 99_buildprep.diff then contains the=20
complete Makefile.in files. The patchsys tries -p0 first, and this actually=20
succeeds in creating these files, but in a subdirectory of the build=20
directory, e.g. kdelibs-3.4.0/kdelibs-3.4.0/Makefile.in. This is when we=20
have to force -p1.

Alternatively, when making a CVS checkout, you could run make -f=20
admin/Makefile.common dist prior to the generation of the .orig.tar.gz, but=20
I don''t really see why one would bother, since this would mix=20
Debian-generated (and Debian-specific, since not everyone uses the same=20
autotools) stuff with KDE CVS.
> moreover, to have the same thing as what you do to build your
> 99.....patch, you can build the package, and then extract from
> the .diff.gz the parts that are not related to debian/ files ;)
>
> but honestly, I don''t really see the point in making it a patch in
> debian/patches since is won''t *really* clean the .diff.gz. It will
only
> make it a bit worse : it will be the same as before, with 2 lines
> added, and a big column of ''+'' ;)
I think it''s nice to have all the build-system stuff in a nice,
separate=20
patch. It can then be removed easily (just unpatch), re-applied, etc.
It''s=20
more a matter of "style" and of how you like to work than an
important=20
technical decision, though as a group we should probably try to be=20
consistent. Comments from anyone and everyone?

Cheers,
Christopher

--nextPart1617725.39j9eIVT2P
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+vtsysRAo5zAJ9H3dtyXvcgLzfG/2O3A09zgNn4/gCeJBUm
eGsg6CyRC5TmC/2I++yCv28=Gxce
-----END PGP SIGNATURE-----

--nextPart1617725.39j9eIVT2P--

* Christopher Martin [Wed, 02 Mar 2005 15:04:12 -0500]:
> The RC1 tarballs dato made available have Makefile.in files provided. I 
> don''t know if dato created them, or whether he just obtained them
this way.
  They were created. It seems that they don''t do it for betas.
> Anyway, we patch them, and everything is fine. If, however, you take a CVS 
> checkout, then these files are generated only when make -f 
> admin/Makefile.common dist is run. The 99_buildprep.diff then contains the 
> complete Makefile.in files. The patchsys tries -p0 first, and this actually
> succeeds in creating these files, but in a subdirectory of the build 
> directory, e.g. kdelibs-3.4.0/kdelibs-3.4.0/Makefile.in. This is when we 
> have to force -p1.
  Ahhh, thanks for this explanation.
> I think it''s nice to have all the build-system stuff in a nice,
separate
> patch. It can then be removed easily (just unpatch), re-applied, etc.
It''s
> more a matter of "style" and of how you like to work than an
important
> technical decision, though as a group we should probably try to be 
> consistent. Comments from anyone and everyone?
  As I said, I agree that the little effort is worth it. Also, note that
  when doing this, "unpack the orig.tar.gz and put the debian/ from SVN
  on it" just works out the box (i.e., no chance of not shipping
  autotools changes because one used the svn dir but forgot to run make
  -f admin/Makefile.common dist).

  Cheers,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
As an adolescent I aspired to lasting fame, I craved factual certainty,
and I thirsted for a meaningful vision of human life -- so I became a
scientist. This is like becoming an archbishop so you can meet girls.
                -- Matt Cartmill

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

On March 2, 2005 16:14, Adeodato Sim=F3 wrote:
>   They were created. It seems that they don''t do it for betas.
Ah, OK. In future, do you prefer to create orig.tar.gz with the build files=20
included, or (my preference) without, the buildprep.diff containing=20
everything?
> > I think it''s nice to have all the build-system stuff in a
nice,
> > separate patch. It can then be removed easily (just unpatch),
> > re-applied, etc. It''s more a matter of "style" and
of how you like to
> > work than an important technical decision, though as a group we should
> > probably try to be consistent. Comments from anyone and everyone?
>
>   As I said, I agree that the little effort is worth it. Also, note that
>   when doing this, "unpack the orig.tar.gz and put the debian/ from
SVN
>   on it" just works out the box (i.e., no chance of not shipping
>   autotools changes because one used the svn dir but forgot to run make
>   -f admin/Makefile.common dist).
True. I had envisioned the buildprep.diff as being created by the uploader=20
every time, but now that you mention it, I suppose we could simply create=20
the buildprep.diff after each upstream release/branch pull/new patch that=20
affects the build system, and check it into svn. Then everything is=20
absolutely standardized, and it''s really easy to start a build.

Cheers,
Christopher

--nextPart1180436.Y1P5iZCBe6
Content-Type: application/pgp-signature

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

iD8DBQBCJjSWU+gWW+vtsysRAoO6AJ0U+6Mp/qqsG7iDd1QmTQ+v7zS6SgCglF3U
l44mlomzlHDYuJ5AUIi0tCU=ISQt
-----END PGP SIGNATURE-----

--nextPart1180436.Y1P5iZCBe6--

* Christopher Martin [Wed, 02 Mar 2005 14:36:21 -0500]:
> >   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.
  The issue is clear: if you put this snippets into kde.mk:
  
common-build-arch:: debian/stamp-man-pages
debian/stamp-man-pages:
# Generate man pages for the programs
        for f in debian/man/*.sgml; do \
                docbook-to-man $$f > debian/man/`basename $$f .sgml`.1; \
        done
        touch debian/stamp-man-pages

clean::
        rm -f debian/man/*.1
        rm -f debian/stamp-man-pages

  You will delete non-generated manpages that exist e.g. in base,
  graphics and multimedia, because they are shipped in debian/man too
  (bindings, otoh, has them in debian/local).

  So, something like this could do instead:

 common-build-arch:: debian/stamp-man-pages
 debian/stamp-man-pages:
 # Generate man pages for the programs
-       for f in debian/man/*.sgml; do \
-                docbook-to-man $$f > debian/man/`basename $$f .sgml`.1; \
+       mkdir debian/man/out
+       for f in $$(find debian/man -name ''*.sgml''); do \
+                docbook-to-man $$f > debian/man/out/`basename $$f .sgml`.1;
\
         done
         touch debian/stamp-man-pages

 clean::
-        rm -f debian/man/*.1
+        rm -rf debian/man/out
         rm -f debian/stamp-man-pages

  And one changes {arts,kdelibs}/debian/*.manpages to use debian/man/out
  as path instead of debian/man alone. (The find instead of the glob is
  to prevent the loop from running in packages that lack .sgml sources.
  A ''test -f'' could have been used instead.)
> > > 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 to
> figure out how to make CDBS work nicely with uuencoded patches. If the 
> built-in patch system can''t do it, we''ll have to handle
it ourselves in
> kde.mk.
  Should be fairly straightforward: a rule on which apply-patches
  depends that just uu-decodes the patches. OTOH...
> >   I intend to write a mail commenting how we manage branch pulls.
  The reason for uu-encoding branch patches is that we use diff -a
  because sometimes there are updates to binary files, e.g. .png images.
  This works, but having .uu patches is not so nice, for a number of
  reasons.

  I was thinking if we couldn''t just make branch pulls with diff -Nru
  only, so that we don''t need to .uu encode them, and them grep the
diff
  for ^Binary and do something with those files. Opinions?

  Such "do something" could be, either do a diff -a for them, and
  uu-encode only that patch, or what Daniel does: put them in a tar,
  uuencode it, and ship that. In his clean target, he just removes the
  files, which afaik would make dpkg-source complain a little about
  "removed files" but nothing else.

  Also, I''d like that we timestamp branch diffs, e.g.
  01_kdelibs_branch_2005-02-27.diff. This was more useful when they were
  uuencoded, but I also like the approach even if they aren''t. Is that
  ok?
> OK. Mind if I remove the debian/stamp-cvs-make stuff then?
  Uhm, yes, in the sense than in cdbs one usually keeps things even if
  he doesn''t use them. More importantly, Daniel may want to use that
  snippets, and I wanted that the kde.mk in svn could be used by all...
  They are properly protected with an env var check, so I can''t see big
  trouble with it.

  Cheers,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
                -- F. Nietzsche

* Christopher Martin [Wed, 02 Mar 2005 16:48:05 -0500]:
> On March 2, 2005 16:14, Adeodato Simó wrote:
> >   They were created. It seems that they don''t do it for
betas.
> Ah, OK. In future, do you prefer to create orig.tar.gz with the build files
> included, or (my preference) without, the buildprep.diff containing 
> everything?
  (Just in case it wasn''t clear, "they were created" meant
"they were
  _already_ created".) As for the question, I don''t mind (and only
will
  affect us when packaging betas). ''without'' is ok, then.
> True. I had envisioned the buildprep.diff as being created by the uploader 
> every time, but now that you mention it, I suppose we could simply create 
> the buildprep.diff after each upstream release/branch pull/new patch that 
> affects the build system, and check it into svn. Then everything is 
> absolutely standardized, and it''s really easy to start a build.
  Exactly.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
If you want the holes in your knowledge showing up try teaching someone.
                -- Alan Cox

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

On March 2, 2005 17:00, Adeodato Sim=F3 wrote:
>   (Just in case it wasn''t clear, "they were created"
meant "they were
>   _already_ created".) As for the question, I don''t mind (and
only will
>   affect us when packaging betas). ''without'' is ok, then.
Ah, sorry, I misread you. I suppose we could check out even the final=20
releases from CVS, avoiding ever shipping pre-built build files, but in the=20
end it''s not that important.

Christopher

--nextPart1801011.ihmQxJyCcB
Content-Type: application/pgp-signature

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

iD8DBQBCJjtHU+gWW+vtsysRAjC8AJ4seWOsiwqFCMZlSpaqMCLloqNaDwCeLKSI
/oeSF+4/q1VCOjAF8ZpwTEA=C0J4
-----END PGP SIGNATURE-----

--nextPart1801011.ihmQxJyCcB--

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

>   The reason for uu-encoding branch patches is that we use diff -a
>   because sometimes there are updates to binary files, e.g. .png
> images. This works, but having .uu patches is not so nice, for a
> number of reasons.
>
>   I was thinking if we couldn''t just make branch pulls with diff
-Nru
>   only, so that we don''t need to .uu encode them, and them grep
the
> diff for ^Binary and do something with those files. Opinions?
>
>   Such "do something" could be, either do a diff -a for them, and
>   uu-encode only that patch, or what Daniel does: put them in a tar,
>   uuencode it, and ship that. In his clean target, he just removes
> the files, which afaik would make dpkg-source complain a little about
> "removed files" but nothing else.
>
>   Also, I''d like that we timestamp branch diffs, e.g.
>   01_kdelibs_branch_2005-02-27.diff. This was more useful when they
> were uuencoded, but I also like the approach even if they aren''t.
Is
> that ok?
for binary files, like png, since they do not have any post-treatments,=20
the simpler way IMHO, is to do sth like that :

debian/patches/01_kdelibs_branch_2005-02-27.diff that only contains=20
textual diffs.

and some debian/updates/01_kdelibs_branch_2005-02-27/ that contains the=20
updated binary files (png, and stuff like that).

then we only have to overwrite the files after they are installed, and=20
all is ok.

=2D-=20
=B7O=B7  Pierre Habouzit
=B7=B7O
OOO                                                http://www.madism.org

--nextPart1687755.QSmhgghmMo
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCJk5WvGr7W6HudhwRApoCAKCF6LE9tRULej6/ZdjYszbmgMYynACfYjXP
D0dnQeaA+N1c+//SjYp5kh0=Eloo
-----END PGP SIGNATURE-----

--nextPart1687755.QSmhgghmMo--

* Christopher Martin [Wed, 02 Mar 2005 17:16:35 -0500]:
> On March 2, 2005 17:00, Adeodato Simó wrote:
> >   (Just in case it wasn''t clear, "they were
created" meant "they were
> >   _already_ created".) As for the question, I don''t mind
(and only will
> >   affect us when packaging betas). ''without'' is ok,
then.
> Ah, sorry, I misread you. I suppose we could check out even the final 
> releases from CVS, avoiding ever shipping pre-built build files, but in the
> end it''s not that important.
  Uhm, now that I think about it, this can be a little insane:

-rw-r--r--   2.3M 
chrsmrtn/3.4-experimental/arts/debian/patches/99_buildprep.diff
-rw-r--r--   9.5M 
chrsmrtn/3.4-experimental/kdelibs/debian/patches/99_buildprep.diff
-rw-r--r--    19M 
chrsmrtn/3.4-experimental/kdebase/debian/patches/99_buildprep.diff

  Though, as I said, it only affects beta releases.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
He who has not a good memory should never take upon himself the trade of lying.
                -- Michel de Montaigne

* Pierre Habouzit [Thu, 03 Mar 2005 00:37:57 +0100]:
> debian/patches/01_kdelibs_branch_2005-02-27.diff that only contains 
> textual diffs.
  Yes.
> and some debian/updates/01_kdelibs_branch_2005-02-27/ that contains the 
> updated binary files (png, and stuff like that).
  But instead of uu-encoding them all, a tar may be wiser. You can check
  Daniel''s code at
http://people.debian.org/~schepler/kde-3.3.91/kdelibs.
> then we only have to overwrite the files after they are installed, and 
> all is ok.
  Overwrite on build, _remove_ on clean... (because restoring would be
  difficult).


  P.S.: Please don''t CC me when you reply on list too.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
When the only tool you have is a hammer, every problem starts to look
like a nail.

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

Le Jeu 3 Mars 2005 07:49, Adeodato Sim=F3 a =E9crit :
> * Pierre Habouzit [Thu, 03 Mar 2005 00:37:57 +0100]:
> > debian/patches/01_kdelibs_branch_2005-02-27.diff that only contains
> > textual diffs.
>
>   Yes.
>
> > and some debian/updates/01_kdelibs_branch_2005-02-27/ that contains
> > the updated binary files (png, and stuff like that).
>
>   But instead of uu-encoding them all, a tar may be wiser. You can
> check Daniel''s code at
> http://people.debian.org/~schepler/kde-3.3.91/kdelibs.
>
> > then we only have to overwrite the files after they are installed,
> > and all is ok.
>
>   Overwrite on build, _remove_ on clean... (because restoring would
> be difficult).
why overwrite on build ?

why not just at install time in debian/tmp/....

with a simple rule like

  cp -r debian/updates/01_kdelibs_branch_2005-02-27/* debian/tmp/

then you don''t have to deal with restoring or such difficult things ...
>   P.S.: Please don''t CC me when you reply on list too.
huu sorry
=2D-=20
=B7O=B7  Pierre Habouzit
=B7=B7O
OOO                                                http://www.madism.org

--nextPart14062374.M07lRR5rvf
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCJrpdvGr7W6HudhwRAnqJAJ9Aih8NYu2GhR+PR755/ZvTg0GSJACgpYl1
1XqDi44cBvxzU5y/8PiRRCs=lcIA
-----END PGP SIGNATURE-----

--nextPart14062374.M07lRR5rvf--

--nextPart2288091.KKc2j2I60B
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Jeu 3 Mars 2005 08:18, Pierre Habouzit a =E9crit :
> Le Jeu 3 Mars 2005 07:49, Adeodato Sim=F3 a =E9crit :
> > * Pierre Habouzit [Thu, 03 Mar 2005 00:37:57 +0100]:
> > > debian/patches/01_kdelibs_branch_2005-02-27.diff that only
> > > contains textual diffs.
> >
> >   Yes.
> >
> > > and some debian/updates/01_kdelibs_branch_2005-02-27/ that
> > > contains the updated binary files (png, and stuff like that).
> >
> >   But instead of uu-encoding them all, a tar may be wiser. You can
> > check Daniel''s code at
> > http://people.debian.org/~schepler/kde-3.3.91/kdelibs.
> >
> > > then we only have to overwrite the files after they are
> > > installed, and all is ok.
> >
> >   Overwrite on build, _remove_ on clean... (because restoring would
> > be difficult).
>
> why overwrite on build ?
>
> why not just at install time in debian/tmp/....
>
> with a simple rule like
>
>   cp -r debian/updates/01_kdelibs_branch_2005-02-27/* debian/tmp/
>
> then you don''t have to deal with restoring or such difficult
things
> ...
and this also work if you have a=20
debian/updates/01_kdelibs_branch_2005-02-27.tar with a simple :

pushd debian/tmp; tar xf ../updates/01_kdelibs_branch_2005-02-27.tar
=2D-=20
=B7O=B7  Pierre Habouzit
=B7=B7O
OOO                                                http://www.madism.org

--nextPart2288091.KKc2j2I60B
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCJr2dvGr7W6HudhwRApmLAKCK/KKo+qHOL5PKf+nxguT/DWk0lwCfYjtN
pjBKJZCIb2nBYkSwcfrfiJ8=NWDy
-----END PGP SIGNATURE-----

--nextPart2288091.KKc2j2I60B--

* Pierre Habouzit [Thu, 03 Mar 2005 08:32:44 +0100]:
> > with a simple rule like
> >   cp -r debian/updates/01_kdelibs_branch_2005-02-27/* debian/tmp/
  Because they must are uu-encoded.
> pushd debian/tmp; tar xf ../updates/01_kdelibs_branch_2005-02-27.tar
  Of course. The whole point of a tar is that you only need to uu-encode
  one file.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
It is impossible to make anything foolproof because fools are so ingenious.