--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-Dsharutils 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 onesI 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-devI 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-devSame as above, with xlibmesa-glu-dev pulled in by Qt.> + remove kdelibs-bin depending on pythonMy 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-dependenciesI''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.tarOf 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.