Bug#579583: marked as done (netatalk: db version missmatch?)
From: Jonas Smedegaard jo...@jones.dk ... This one is not a bug, however, but a shortcoming of upstream code which cause breakage each time we bump the BerkeleyDB version. Rescue is near though, from the manual [1]: Note that the first version to appear after Netatalk 2.1 ie Netatalk 2.1.1, will support BerkeleyDB updates on the fly without manual intervention. In other words Netatalk 2.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before. That means it can't upgrade a 2.0.x version because that one didn't prepare the database. Cheers, Frank! [1] http://netatalk.sourceforge.net/2.1/htmldocs/configuration.html#CNID-backends -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579583: marked as done (netatalk: db version missmatch?)
2010/4/29 Jonas Smedegaard jo...@jones.dk: On Thu, Apr 29, 2010 at 02:07:37PM +0200, Frank Lahm wrote: From: Jonas Smedegaard jo...@jones.dk ... This one is not a bug, however, but a shortcoming of upstream code which cause breakage each time we bump the BerkeleyDB version. Rescue is near though, from the manual [1]: Note that the first version to appear after Netatalk 2.1 ie Netatalk 2.1.1, will support BerkeleyDB updates on the fly without manual intervention. In other words Netatalk 2.1 does contain code to prepare the BerkeleyDB database for upgrades and to upgrade it in case it has been prepared before. That means it can't upgrade a 2.0.x version because that one didn't prepare the database. Yes. Looking very much forward to that. When is the new release due? 2.1 final has been released on Monday! ;) 2.1.1 will be released whenever we have fixed enough bugs. 2.2 relese is scheduled for December. -Frank -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559060: netatalk: FTBFS due to autoreconf issues when autotools are installed
2009/12/1 Cyril Brulebois k...@debian.org:
Jonas Smedegaard d...@jones.dk (01/12/2009):
My builds using cowdancer+pbuilder on amd64 and i386 with a fully
up-to-date Sid shows no such things.
Note I'm talking about porter boxes, so a bit more than just chroot +
Build-Depends.
Perhaps some environment variables makes cdbs or libtool choke, or
some old version of libtool makes netatalk choke. Could you please
tell more about the build environment (e.g. versions of installed
packages and environment variables set), to shed some light on what
is going on here?
I've cleaned up all autotools packages and only installed those that
the build system tries to use (as seen in the build log):
$ dpkg -l 'autoconf*' 'automake*' libtool|grep ^ii|awk '{print $2 / $3}'
autoconf/2.65-2
automake1.10/1:1.10.2-2
libtool/2.2.6a-4
You're (well not you, the Debian build infrastructure) messing up the
autotools environment. Netatalk 2.0.5 comes with:
$ ./libtool --version
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365
2005/12/18 22:14:06)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So if you want to regenerate, do so completely eg run `libtoolize
--force --copy` and maybe also `automake --include-deps --add-missing
--foreign --copy`.
The alternative is to stay away from configure.in and Makefile.am.
-Frank
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533141: Current netatalk fails to build from source
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. -Frank, Netatalk Developer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533141: Current netatalk fails to build from source
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. @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 -Frank -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533141: Current netatalk fails to build from source
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533141: Current netatalk fails to build from source
2009/6/16 Jonas Smedegaard d...@jones.dk 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. ?? Bingo! Until recently I regenerating files, and then switched back to applying patches only. I clearly missed that configure.in still got patched. Thanks a lot for spotting this. The error is mine. I will fix this for the next release (where I will also bump to the official upstream release)! Great! As said, there are a few more patches doing that, e.g. the zeroconf patch. 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. From my current knowledge, I do not even think that AM_MAINTAINER_MODE would have helped here: I broke the chain, I need to fix it. Probably the error code would have been different like autoconf not installed or whatever error is thrown exactly when automake reruns the autotools chain and one of the tools is not installed on the host. 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. Thanks. And sorry again for my misunderstanding and biting at you. No problem. -Frank -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533141: Current netatalk fails to build from source
2009/6/15 Itai Seggev is+deb...@cs.hmc.edu: Package: netatalk Version: 2.0.4~rc2-1 Severity: serious Okay, perhaps I am cluless or there's something seriously wrong with my system, but this has never failed me in the past. I am try to rebuild the package from source to enable openSSL. Please re-read the netatalk 2.0.4 release notes. For encrypted password support netatalk now can use libgcrypt instead of OpenSSL. libgcrypt is used by the DHX2 authentication mech. BTW (and perhaps this should be its own separate bug), the README.Debian seems to suggest openssl support is not need to connect to OS X 10.4 and higher, but TimeMachine won't connect with the stock build. I'm not sure if I'm misunderstanding the readme me, it is wrong, or I have some misconfiguration. Needed authentication mechanisms for certain OS X releases is an entirely different issue then TimeMachine support. 10.5 requires some encrypted password mech (DHX, DHX2, randnum, gss) while TimeMachine is not supported with 2.0.4. It will be in 2.1. Please remember to report upstream fixable issues upstream. -Frank -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
