Closed IvanExpert closed 8 years ago
knghtbrd
commented
8 years ago Notably, Debian sid has a 2.2.5 package, though it is considered to need work and it was excluded from jessie due to multiple issues that render it unsuited for release. We probably ought to examine these bugs at some point, as well as a diff between 2.2.4 and 2.2.5. A partial reversion patch is probably in order from the looks of it.
IvanExpert
commented
8 years ago Do you mean we should be somehow patching the Sid package? It's almost certainly compiled without a2boot support, and possibly without randnum support also, and likely without DDP support, which is disabled by default on 2.2.x. Ours is set up just as we need, and it's the heart of the project; and we patch the code ourselves. I don't have any real confidence in 2.2.5 as a whole. I vote nay, unless persuaded otherwise, like something demonstrably superior about 2.2.5 discovered in a diff, and even then I think we should be rolling our own.
On Dec 3, 2015, at 5:09 PM, Joseph Carter notifications@github.com wrote:
Notably, Debian sid has a 2.2.5 package, though it is considered to need work and it was excluded from jessie due to multiple issues that render it unsuited for release. We probably ought to examine these bugs at some point, as well as a diff between 2.2.4 and 2.2.5. A partial reversion patch is probably in order from the looks of it.
— Reply to this email directly or view it on GitHub.
knghtbrd
commented
8 years ago We have to roll our own for jessie regardless—the package isn't
there. What I'm starting to consider (and I need to do some research
to see if it can be done) is that perhaps we may be able to modify
netatalk 2.x to be DDP-only (with a2boot enabled) and have it coexist
alongside netatalk 3.x. Want modern features? Install netatalk 3.x.
Want old Mac and Apple // support? Install netatalk 2.x. Want both?
Install both on the same machine.
But I don't want to get bogged down doing that while we're trying to get a jessie release out the door. It's definitely a bigger project and not one I'm ready to take on. That's why I haven't even started looking into it yet.
Joseph
On Thu, Dec 03, 2015 at 02:29:10PM -0800, IvanExpert wrote:
Do you mean we should be somehow patching the Sid package? It's almost certainly compiled without a2boot support, and possibly without randnum support also, and likely without DDP support, which is disabled by default on 2.2.x. Ours is set up just as we need, and it's the heart of the project; and we patch the code ourselves. I don't have any real confidence in 2.2.5 as a whole. I vote nay, unless persuaded otherwise, like something demonstrably superior about 2.2.5 discovered in a diff, and even then I think we should be rolling our own.
On Dec 3, 2015, at 5:09 PM, Joseph Carter notifications@github.com wrote:
Notably, Debian sid has a 2.2.5 package, though it is considered to need work and it was excluded from jessie due to multiple issues that render it unsuited for release. We probably ought to examine these bugs at some point, as well as a diff between 2.2.4 and 2.2.5. A partial reversion patch is probably in order from the looks of it.
— Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161807751
IvanExpert
commented
8 years ago That all sounds very reasonable.
It's certainly possible to have Netatalk be DDP-only just by configuring it that way in atalkd.conf.
On Dec 3, 2015, at 7:07 PM, Joseph Carter notifications@github.com wrote:
We have to roll our own for jessie regardless—the package isn't there. What I'm starting to consider (and I need to do some research to see if it can be done) is that perhaps we may be able to modify netatalk 2.x to be DDP-only (with a2boot enabled) and have it coexist alongside netatalk 3.x. Want modern features? Install netatalk 3.x. Want old Mac and Apple // support? Install netatalk 2.x. Want both? Install both on the same machine.
But I don't want to get bogged down doing that while we're trying to get a jessie release out the door. It's definitely a bigger project and not one I'm ready to take on. That's why I haven't even started looking into it yet.
Joseph
On Thu, Dec 03, 2015 at 02:29:10PM -0800, IvanExpert wrote:
Do you mean we should be somehow patching the Sid package? It's almost certainly compiled without a2boot support, and possibly without randnum support also, and likely without DDP support, which is disabled by default on 2.2.x. Ours is set up just as we need, and it's the heart of the project; and we patch the code ourselves. I don't have any real confidence in 2.2.5 as a whole. I vote nay, unless persuaded otherwise, like something demonstrably superior about 2.2.5 discovered in a diff, and even then I think we should be rolling our own.
On Dec 3, 2015, at 5:09 PM, Joseph Carter notifications@github.com wrote:
Notably, Debian sid has a 2.2.5 package, though it is considered to need work and it was excluded from jessie due to multiple issues that render it unsuited for release. We probably ought to examine these bugs at some point, as well as a diff between 2.2.4 and 2.2.5. A partial reversion patch is probably in order from the looks of it.
— Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161807751 — Reply to this email directly or view it on GitHub.
knghtbrd
commented
8 years ago The major thing involved will be making netatalk2 not clobber netatalk3. Might need a separate database if they both share the same directory. Will definitely need separate config files so that they can each have their own list of shares and configurations. And probably we'd want to strip TCP out of netatalk2, which would mean less code we had to worry about maintaining. After all, that's why netatalk3 stripped out the stuff we use: They didn't want to maintain multiple code paths that few people would ever use.
Joseph
On Thu, Dec 03, 2015 at 04:56:59PM -0800, IvanExpert wrote:
That all sounds very reasonable.
It's certainly possible to have Netatalk be DDP-only just by configuring it that way in atalkd.conf.
On Dec 3, 2015, at 7:07 PM, Joseph Carter notifications@github.com wrote:
We have to roll our own for jessie regardless—the package isn't there. What I'm starting to consider (and I need to do some research to see if it can be done) is that perhaps we may be able to modify netatalk 2.x to be DDP-only (with a2boot enabled) and have it coexist alongside netatalk 3.x. Want modern features? Install netatalk 3.x. Want old Mac and Apple // support? Install netatalk 2.x. Want both? Install both on the same machine.
But I don't want to get bogged down doing that while we're trying to get a jessie release out the door. It's definitely a bigger project and not one I'm ready to take on. That's why I haven't even started looking into it yet.
Joseph
On Thu, Dec 03, 2015 at 02:29:10PM -0800, IvanExpert wrote:
Do you mean we should be somehow patching the Sid package? It's almost certainly compiled without a2boot support, and possibly without randnum support also, and likely without DDP support, which is disabled by default on 2.2.x. Ours is set up just as we need, and it's the heart of the project; and we patch the code ourselves. I don't have any real confidence in 2.2.5 as a whole. I vote nay, unless persuaded otherwise, like something demonstrably superior about 2.2.5 discovered in a diff, and even then I think we should be rolling our own.
On Dec 3, 2015, at 5:09 PM, Joseph Carter notifications@github.com wrote:
Notably, Debian sid has a 2.2.5 package, though it is considered to need work and it was excluded from jessie due to multiple issues that render it unsuited for release. We probably ought to examine these bugs at some point, as well as a diff between 2.2.4 and 2.2.5. A partial reversion patch is probably in order from the looks of it.
— Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161807751 — Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161840753
IvanExpert
commented
8 years ago This all makes sense and seems like a worthwhile goal.
However, it sounds scary to have Netatalk 2 and 3 sharing the same folders, and if we strip TCP out of Netatalk 2, then we'll be unable to connect to it from modern Macs on the network via AFP -- and if we connect via SMB, the file metadata won't be recognized, making it not possible to copy, say, a GS/OS application file to a modern Mac and back. I think the Apple II share being accessible to and on equal footing with modern computers on the network is one of A2SERVER's most important capabilities, and now it's that much more available with the case insensitive fs.
So it seems like the options are, in order of my own preference:
knghtbrd
commented
8 years ago I don't see your preferences as mutually exclusive. Your first preference seems like the ideal short-term solution. Netatalk 2 is still supported by even current Mac OS X machines. It solves the immediate problem.
The idea of 2 and 3 coexisting, if their databases are compatible or the two can coexist, cannot be a short term solution because it requires investigation if nothing else. I do know that it seems that netatalk (and apparently Mac System 7 even) ignores all of the stuff about ProDOS in the resource fork format and just overloads Mac fields in ways that don't break anything--so it's just a matter of the database itself.
That's enough to define the problem domain for the time being. I think our netatalk will be packaged as netatalk2 and conflict with netatalk (and thus whatever version Debian has packaged.) If in the future that changes, we can adjust things.
Joseph
On Fri, Dec 04, 2015 at 06:22:13AM -0800, IvanExpert wrote:
This all makes sense and seems like a worthwhile goal.
However, it sounds scary to have Netatalk 2 and 3 sharing the same folders, and if we strip TCP out of Netatalk 2, then we'll be unable to connect to it from modern Macs on the network via AFP -- and if we connect via SMB, the file metadata won't be recognized, making it not possible to copy, say, a GS/OS application file to a modern Mac and back. I think the Apple II share being accessible to and on equal footing with modern computers on the network is one of A2SERVER's most important capabilities, and now it's that much more available with the case insensitive fs.
So it seems like the options are, in order of my own preference:
- Require that A2SERVER users stick with 2, and refuse to install if 3 is present (and possibly offer to uninstall it and take over its shares, if that's feasible). Least work, most predictability. It's not as if Netatalk 2 doesn't support modern AFP (and if someone can't use A2SERVER as a Time Machine host, I can live with that).
- Determine it's safe to share the same folder from 2 and 3 at the same time, and use 2 for DDP and 3 for TCP. I'm not sure how we make this determination, as much has changed in 3, and it sounds shaky; I suppose we could ask the project authors.
- Require modern Macs to connect via SMB, at a cost of metadata compatibility with Apple II and classic Mac clients. I'd have to be persuaded for this one -- I don't think whatever 3 has to offer is worth the tradeoffs of reduced modern Mac functionality.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161979033
IvanExpert
commented
8 years ago Ok, that works.
On Dec 5, 2015, at 1:39 AM, Joseph Carter notifications@github.com wrote:
I don't see your preferences as mutually exclusive. Your first preference seems like the ideal short-term solution. Netatalk 2 is still supported by even current Mac OS X machines. It solves the immediate problem.
The idea of 2 and 3 coexisting, if their databases are compatible or the two can coexist, cannot be a short term solution because it requires investigation if nothing else. I do know that it seems that netatalk (and apparently Mac System 7 even) ignores all of the stuff about ProDOS in the resource fork format and just overloads Mac fields in ways that don't break anything--so it's just a matter of the database itself.
That's enough to define the problem domain for the time being. I think our netatalk will be packaged as netatalk2 and conflict with netatalk (and thus whatever version Debian has packaged.) If in the future that changes, we can adjust things.
Joseph
On Fri, Dec 04, 2015 at 06:22:13AM -0800, IvanExpert wrote:
This all makes sense and seems like a worthwhile goal.
However, it sounds scary to have Netatalk 2 and 3 sharing the same folders, and if we strip TCP out of Netatalk 2, then we'll be unable to connect to it from modern Macs on the network via AFP -- and if we connect via SMB, the file metadata won't be recognized, making it not possible to copy, say, a GS/OS application file to a modern Mac and back. I think the Apple II share being accessible to and on equal footing with modern computers on the network is one of A2SERVER's most important capabilities, and now it's that much more available with the case insensitive fs.
So it seems like the options are, in order of my own preference:
- Require that A2SERVER users stick with 2, and refuse to install if 3 is present (and possibly offer to uninstall it and take over its shares, if that's feasible). Least work, most predictability. It's not as if Netatalk 2 doesn't support modern AFP (and if someone can't use A2SERVER as a Time Machine host, I can live with that).
- Determine it's safe to share the same folder from 2 and 3 at the same time, and use 2 for DDP and 3 for TCP. I'm not sure how we make this determination, as much has changed in 3, and it sounds shaky; I suppose we could ask the project authors.
- Require modern Macs to connect via SMB, at a cost of metadata compatibility with Apple II and classic Mac clients. I'd have to be persuaded for this one -- I don't think whatever 3 has to offer is worth the tradeoffs of reduced modern Mac functionality.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-161979033 — Reply to this email directly or view it on GitHub.
IvanExpert
commented
8 years ago So, as of tag 1.2.7fc1, A2SERVER (but not A2CLOUD or Raspple II) has preliminary support for Jessie. The issues, as mentioned above, is that Netatalk 2.2.4 was made to support libdb5.1 and libgcrypt11, both of which are in Wheezy, but which have been replaced by libdb5.3 and libgcrypt20 in Jessie. (However, there is a libgcrypt11-dev transitional package in Jessie.)
So there are two ways to approach this, and both seem to work fine:
I opted for the latter approach for the 1.3.0 pending release, since it seemed to involve the fewest unknown conditions, but I think it probably merits a discussion as to whether this is the right thing to do, as well as whether Netatalk should be built with its --enable-systemd configure option or otherwise rework its init.d scripts when run on Jessie.
Maybe this issue and the two other Jessie support related issues and be merged.
knghtbrd
commented
8 years ago Since that's now been merged in as of b5496b5, it actually seems this issue is safe to close as fixed as of then, unless you feel a need to keep the issue around a little longer?
IvanExpert
commented
8 years ago No, feel free to close it,
IvanExpert
commented
8 years ago I changed my mind about this, and decided that we should use what's in Jessie (libgcrypt20 and libdb5.3), particularly after the hell that nearly broke loose when I tried to apt-get remove the manually installed libdb5.1.
There will be a separate precompiled binary for Netatalk for Jessie and Wheezy, and if not available it will build against the newer libraries.
Leaving open until this is implemented.
knghtbrd
commented
8 years ago My figuring is that we can use any package that is available in the distribution for a binary, but we should always favor the preferred development packages for the distribution. The later packages are preferred in jessie, and they work, so that seems like a good policy for the time being.
IvanExpert
commented
8 years ago So, this is interesting -- while Debian Wheezy only has libdb5.1 on offer, Raspbian Wheezy has both libdb5.1 and libdb5.3. Because I have more faith and confidence in Netatalk 2.2.4 being qualified on 5.1, and to keep things consistent across platforms, I'm going to reverse the priority in the if...elif to prefer libdb5.1 if it's available (meaning Wheezy -- it's not in either Jessie, I checked). Over time, this may be reversed or 5.1 removed once we're confident that 5.3 is fine. I am sure this is close to the scenario that led to 4.8 being preferred over 5.1 in the scripts a while back.
knghtbrd
commented
8 years ago I think 5.3 was probably a Raspbian backport. You already detect wheezy vs. jessie, so that seems appropriate to do now.
Joseph
On Sun, Jan 03, 2016 at 01:39:35PM -0800, IvanExpert wrote:
So, this is interesting -- while Debian Wheezy only has libdb5.1 on offer, Raspbian Wheezy has both libdb5.1 and libdb5.3. Because I have more faith and confidence in Netatalk 2.2.4 being qualified on 5.1, and to keep things consistent across platforms, I'm going to reverse the priority in the if...elif to prefer libdb5.1 if it's available (meaning Wheezy -- it's not in either Jessie, I checked). Over time, this may be reversed or 5.1 removed once we're confident that 5.3 is fine. I am sure this is close to the scenario that led to 4.8 being preferred over 5.1 in the scripts a while back.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-168542702
IvanExpert
commented
8 years ago Actually, it appears to be in main, but I don't know if that means anything.
knghtbrd
commented
8 years ago It doesn't since Raspbian maintain separate -backports repos. It's fair to consider Raspbian to be a Debian-derived distribution rather than merely a Debian port. It just changes a lot less than Ubuntu or others do.
Joseph
On Sun, Jan 03, 2016 at 03:19:39PM -0800, IvanExpert wrote:
Actually, it appears to be in main, but I don't know if that means anything.
Reply to this email directly or view it on GitHub: https://github.com/RasppleII/a2server/issues/48#issuecomment-168551596
IvanExpert
commented
8 years ago Yes, I'd agree -- Raspbian is a distro, not merely a port. Closing this issue.
This is a catchall issue for possible future Netatalk 2.2.4 (and other A2SERVER/A2CLOUD) dependency issues.
Netatalk 2.2.4 is the last reliable version that includes DDP (AppleTalk) networking. (Netatalk 2.2.5 doesn't even compile on Debian; Netatalk 3.0+ excises DDP.)
Key question: is it preferable to run Netatalk 2.2.4 against newer versions of dependencies that it hasn't been tested on, or is it preferable to install the older, supported dependency versions into the newer operating system? My bias is towards the latter, but I don't know what the implications are.
Known current issues:
Berkeley DB (libdb) -- 2.2.4 depends on libdb4.6 through 5.1. I don't know whether new versions of libdb are intended to be backwards compatible with previous ones, but Jessie includes 5.3. Netatalk still finds that and compiles if libdb5.3-dev is present, and the object code appears to operate correctly, but it's not known whether this is expected to work, or if it will stop working in future versions of libdb. It is possible to install libdb5.1 (from Wheezy) into Jessie with:
wget http://ftp.debian.org/debian/pool/main/d/db/libdb5.1_5.1.29-5_i386.debdpkg -i libdb5.1_5.1.29-5_i386.deblibgcrypt -- 2.2.4 depends on libgcrypt11, whereas Jessie includes libgcrypt20. There is, however, a libgcrypt11-dev transitional package, so for the time being, Netatalk compiles if that's installed. It seems likely this will go away in the future, though. I don't know wheter libgcrypt20 is backwards compatible. It is possible to install libgcrypt11 (from Wheezy) into Jessie with:
wget http://ftp.debian.org/debian/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-5+deb7u3_i386.deblibgcrypt11_1.5.0-5+deb7u3_i386.debI have tested compiling against the newer versions, and that seems to work; I have also installed the older libraries and installed the Netatalk binary tarball for Wheezy, and that works too.