2009/6/16 Jonas Smedegaard <d...@jones.dk> > On Tue, Jun 16, 2009 at 11:59:23AM +0200, Frank Lahm wrote: > >2009/6/16 Jonas Smedegaard <d...@jones.dk> > >> On Tue, Jun 16, 2009 at 10:33:23AM +0200, Frank Lahm wrote: > >> >2009/6/16 Itai Seggev <is+deb...@cs.hmc.edu> > >> >> Any other suggestions? > >> > > >> >Although you're only reporting this problem with a rc and the final > >> >is alread available, whatever causes your error may still be > >> >present. Therefore I'm digging into this and will be talkin to the > >> >libtool folks. Stay tuned. > >> > >> I believe that this issue can be solved upstream by adding > >> AM_MAINTAINER_MODE to configure.in and using a more recent libtool > >> when preparing release tarballs. > > > >I've just took another look at Debian list of patches to netatalk. As > >it seems you're touching configure.in amongst others. I'm not familiar > >with the workings of the Debian package building tools, but I guess in > >order for these patches to be applied they must re-run the Autotools > >toolchain, do they? If they do, it might be an issue in how they do > >that. > > Yes, that might certainly be an issue. And if that is an issue, the > solution is *not* to compile unpatched code by hand, but to fix that > issue.
I was suggesting to _compile_ and see if the issue comes from upstream or from your patches. I wasn't suggesting to compile and run that "unpatched code" ! I'm trying to track it down in order to fix it. > You've asked those patches before, and I told you not (as upstream) to > worry about those pathces to autogenerated files): I agree that they are > not of concern for upstream. But you are *not* patching _generated_ files here. You are patching configure.in in this case. ?? > ... > I believe that the problem here is *not* with those files, however. As > I wrote already, I beleive it is tied to libtool: Debian use a much > newer libtool that used upstream, and it seems (also experienced in > other packages that I maintain) that if libtool acts up (which can be > suppressed my AM_MAINTAINER_MODE that you sadly do not use currently), > then too big differences in versions of libtool and automake won't work. AM_MAINTAINER_MODE might indeed fix this issue, but afaict the problem is caused because you touch autoconf stuff (configure.in, m4 macros) and rerun autotools. AM_MAINTAINER_MODE can then prevent this problem from occurring because it ensures proper regenaration of the toolchain (that's really all it does -- not some kind of libtool versioning check or whatever). > That's why I explicitly requestes to test from scratch, not continue to > try build same unpacked source, that has now gone sour. Good idea of course. > >@Itai: please try to configure and make the unpatched tarball as > >available from the Debian archive > ><http://ftp.de.debian.org/debian/pool/main/n/netatalk/netatalk_2.0.4~rc2.orig.tar.gz> > > What would be the point of such test? See whether your patches and build system cause problems or the problem is caused by the netatalk package _as is_. > Please note that this Bug Tracker relates to packaged software, not > upstream. Yeah, and bugs that effect upstream have always been reported there too... I'm just actively digging into this because I'm afraid it might be some _upstream_ issue. -Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
