tags 284854 -moreinfo thanks Neil,
On Tue, Sep 11, 2007 at 10:03:00AM +0100, Neil Williams wrote: > I need some help with patching pam - I must admit I don't like quilt, > I find it hard to use and understand, especially when I am trying to > modify the quilt patches for someone else's package. > :-( > (Is there was a standard way of using quilt that doesn't rely on > prefixing every command with QUILT_PATCHES= ? *and* which is portable > to *all* Debian packages using quilt no matter whether the package > uses debian/patches debian/patches-applied or debian/manglesource or > debian/foo ?) No, there is not. I will probably move the debian/patches-applied directory to debian/patches in some future revision of pam, but there are higher priorities, like getting caught up with upstream's latest release and trying to minimize the number of Debian patches we're carrying in the first place. But why wouldn't you just export QUILT_PATCHES in your shell instead of setting it with every command? > Could there be a debian/rules target that would allow people like me to > work with quilt in any package without having to know about > QUILT_PATCHES ? No. How would a debian/rules target set the QUILT_PATCHES variable in your environment to let you work with quilt? > (I much prefer to CDBS method of "just drop the patch file in and build".) This is a toy, not a real patch management system. But if all you want is to drop in a new patch, you can do that easily enough by adding one file to debian/patches-applied and adding its name to debian/patches-applied/series. Quilt is not notably more difficult to work with than cdbs-simplepatchsys for trivial cases -- it's that packages which use quilt are *not* the trivial use cases covered by cdbs's simplepatchsys. > Now this is because pam does not support CC_FOR_BUILD which should be > used to allow cross-builds to use gcc to build internal tools that are > expected to be run during the build (and which would then have to be > cleaned and rebuilt if these were to be packaged). > These are the preliminary changes I need to make to support CC_FOR_BUILD: > Index: pam-0.99.7.1/Linux-PAM/configure.in > =================================================================== > --- pam-0.99.7.1.orig/Linux-PAM/configure.in 2007-09-11 > 09:16:59.000000000 +0100 +++ pam-0.99.7.1/Linux-PAM/configure.in > 2007-09-11 09:17:02.000000000 +0100 @@ -72,6 +72,12 @@ > PAM_LD_AS_NEEDED > PAM_LD_O1 > > +if test x"$cross_compiling" = xyes; then > + AC_CHECK_PROGS(CC_FOR_BUILD, gcc cc) > +else > + CC_FOR_BUILD="$CC" > +fi > + > dnl Largefile support > AC_SYS_LARGEFILE > > > Index: pam-0.99.7.1/Linux-PAM/doc/specs/Makefile.am > =================================================================== > --- pam-0.99.7.1.orig/Linux-PAM/doc/specs/Makefile.am 2007-09-11 > 09:16:59.000000000 +0100 +++ > pam-0.99.7.1/Linux-PAM/doc/specs/Makefile.am 2007-09-11 > 09:17:02.000000000 +0100 @@ -11,6 +11,8 @@ > AM_YFLAGS = -d > > +CC = @CC_FOR_BUILD@ > + > BUILT_SOURCES = parse_y.h > > noinst_PROGRAMS = padout Ok. I'll probably push this patch upstream first and pull it back down with the next upstream release; we have enough local Debian patches right now without adding more feature patches. > (CC_FOR_BUILD support for cross-building in Debian is only available > via the experimental version of dpkg-cross (>= 1.99+2.0.0pre2-1) along > with apt-cross (>= 0.2.9) (from Emdebian SVN) and emdebian-tools (>= > 0.3.9) (from Emdebian SVN) *and* a patched version of > dpkg-buildpackage from #439979 [0]. However, all these changes are > being incorporated into the main packages in due course.) Sorry, in what sense is any support for CC_FOR_BUILD needed there at all? What I see above is a self-contained autoconf rule. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
