koffice/debian
CVS commit by benb: Updated karbon pixmap. M +210 -180 karbon.xpm 1.4
Re: koffice/debian
On Sat, Nov 01, 2003 at 07:37:04AM +0100, Ben Burton wrote: > CVS commit by benb: > > Force a rerun of automake/etc since the debian patches require it. > > > M +8 -4 rules 1.93 > > > --- koffice/debian/rules #1.92:1.93 > @@ -63,7 +63,11 @@ > > # KDE CVS does not have aclocal.m4 or configure > -if test ! -f configure; then \ > -$(MAKE) -f admin/Makefile.common ;\ > -fi > +# if test ! -f configure; then \ > +# $(MAKE) -f admin/Makefile.common ;\ > +# fi > + > +# Force a rerun of automake/etc since this is required by the > +# debian patches. > +$(MAKE) -f admin/Makefile.common ;\ This really shouldn't be done like this since it requires autotools for the build environment. The way I have been working around it myself is to have the autotools stuff installed in my chroot for the initial build (eg not buildd's) then after the patches are applied run make -f admin/Makefile.common by hand so that they are included in the diff.gz. However, if you do this you will need the AM_MAINTAINER_MODE patch as well, which actually is probably faster regardless since it disables the automake up to date checks. BTW - I have also started using pristine tagged cvs export's (eg KDE_3_1_4_RELEASE) then runing make -f admin/Makefile.common once, removing the automake cache dir and then taring that as the orig.tar.gz. Everything else I change I put into patches. Apparently this helps make the security team much more happier than having random stuff in the diff.gz (like all of a BRANCH update). ;) I hope the above made sense its 2am here. Chris signature.asc Description: Digital signature
Re: koffice/debian
> This really shouldn't be done like this since it requires autotools for > the build environment. koffice build-depends on automake/etc, so it shouldn't break anything. This actually doesn't change anything from koffice's behaviour over the last couple of years - I simply added the patch now because I was building from an upstream tarball instead of from a CVS checkout. Your method does look reasonable for packages that don't have patched Makefile.ams. Though koffice does (have patched Makefile.ams), and part of the reason for running automake at build time is the patches can all stay in the one place (debian/patches). This requires automake to be run at build time since the patches are applied at build time. I'm presuming the reason the debian/patches system was first introduced was to make it easier for other people to make builds from random CVS checkouts, which suits me fine. Anyway, koffice is uploading now and a whole lot of build structures are about to change with the move to alioth, so since nothing is broken I'm quite happy to leave this discussion till after the alioth thing settles down and koffice has another upstream release. b.
Re: koffice/debian
On Sat, Nov 01, 2003 at 08:06:36PM +1100, Ben Burton wrote: > > > This really shouldn't be done like this since it requires autotools for > > the build environment. > > koffice build-depends on automake/etc, so it shouldn't break anything. This only doesn't break anything as long as automake is forced to run on every build. Otherwise every minor revision upgrade of automake will break the build. > This actually doesn't change anything from koffice's behaviour over the > last couple of years - I simply added the patch now because I was > building from an upstream tarball instead of from a CVS checkout. As you mentioned below once we move to alioth we will probably want to make sure everything builds in a similiar fashion. We can wait to discuss it further until then. > Your method does look reasonable for packages that don't have patched > Makefile.ams. Though koffice does (have patched Makefile.ams), and part > of the reason for running automake at build time is the patches can all > stay in the one place (debian/patches). This requires automake to be > run at build time since the patches are applied at build time. I'm > presuming the reason the debian/patches system was first introduced was > to make it easier for other people to make builds from random CVS > checkouts, which suits me fine. The method I use is specifically for when original (ungenerated) build files have to be modified (ie configure.in, Makefile.am, etc). There are some other problems with using make cvs-clean that I will go into later if you want to know, which afaict is the only way to clean up after running automake at build time. > Anyway, koffice is uploading now and a whole lot of build structures are > about to change with the move to alioth, so since nothing is broken I'm > quite happy to leave this discussion till after the alioth thing settles > down and koffice has another upstream release. Ok. Chris signature.asc Description: Digital signature
Re: koffice/debian
> > koffice build-depends on automake/etc, so it shouldn't break anything. > > This only doesn't break anything as long as automake is forced to run on > every build. Otherwise every minor revision upgrade of automake will > break the build. Well since automake is run during the configure target, the only problem I can see is if you use the same build tree without remaking the configure target across a system upgrade. Which can cause problems for more than automake - configure tests a vast number of properties of the system configuration, and developers should not be surprised by having to rerun configure from time to time after an upgrade. And of course they won't experience silent breakage or anything nasty like that - automake will tell them explicitly that it needs to be rerun. b.
koffice/debian
CVS commit by benb:
Change OOo mimelnk suggests to recommends.
M +8 -0 changelog 1.149
M +2 -1 control 1.120
--- koffice/debian/changelog #1.148:1.149
@@ -1,2 +1,10 @@
+koffice (1:1.3.0-1) unstable; urgency=low
+
+ * New upstream release (1.3-final).
+ * Changed suggests openoffice.org-mimelnk to recommends now that OOo is in
+main.
+
+ -- Ben Burton <[EMAIL PROTECTED]> Mon, 3 Nov 2003 11:18:03 +1100
+
koffice (1:1.2.94-1) unstable; urgency=low
--- koffice/debian/control #1.119:1.120
@@ -187,5 +187,6 @@
Section: libs
Depends: koffice-libs (= ${Source-Version})
-Suggests: openoffice.org-mimelnk, khelpcenter, koffice-doc-html
+Recommends: openoffice.org-mimelnk
+Suggests: khelpcenter, koffice-doc-html
Conflicts: koffice-libs (<< 1:1.2.90-0), kugar (<< 1:1.2.90-0)
Replaces: koffice-libs (<< 1:1.2.90-0), kugar (<< 1:1.2.90-0)
koffice/debian
CVS commit by benb: Force a rerun of automake/etc since the debian patches require it. M +8 -4 rules 1.93 --- koffice/debian/rules #1.92:1.93 @@ -63,7 +63,11 @@ # KDE CVS does not have aclocal.m4 or configure -if test ! -f configure; then \ -$(MAKE) -f admin/Makefile.common ;\ -fi +# if test ! -f configure; then \ +# $(MAKE) -f admin/Makefile.common ;\ +# fi + +# Force a rerun of automake/etc since this is required by the +# debian patches. +$(MAKE) -f admin/Makefile.common ;\ # make build directory @@ -117,5 +121,5 @@ fi -if test -f Makefile.cvs; then \ +if test -d CVS; then \ $(MAKE) -f admin/Makefile.common cvs-clean ;\ fi
