Re: Where does the Latest Version Work?
"Henry B (Hank) Hotz, CISSP" <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.heimdal.general |
|---|---|
| Message-ID | <[email protected]> |
> On Aug 11, 2016, at 6:37 PM, Jeffrey Altman <[email protected]> wrote: > > On 8/11/2016 9:21 PM, Henry B (Hank) Hotz, CISSP wrote: >> I can get Heimdal 1.6 to work with some fiddling. >> >> There doesn’t seem to be a 1.7 branch in GIT. > > Nor will there be. The next version will be 7.0 but when using Git > there is no benefit to branching until there is a separation between > master and what is going to be tagged. Since there is no such > separation, there is no branch. > >> The bleeding-edge version doesn’t seem to be usable. > > Usable for what? Well, anything at all . . . If you want something specific I would say that the autogen.sh script doesn’t work. As a minimum a few mods to configure.ac to enable some m4 backward-compatibility options are needed. Past that, on NetBSD it dies with “automate: cannot open automate.cache/requests: Permission denied”. I got past that on Debian, but I forget how. NetBSD is my actual target. I assume this is a harbinger of the compile problems I’ll have to deal with. > The master branch is in production at a number of sites. I find that difficult to believe, but if there is some specific combination of things that is known to work out-of-the-box, that’s what I’m asking for. >> Since I believe there are people on this list actually doing development on Heimdal, where are you doing it? > > I assume that depends on the developer. AuriStor Inc builds master on > recent 64-bit Linux under Coverity nightly. I also periodically build > Windows and periodically on Solaris. > >> I’ve tried the latest Debian and NetBSD versions and get fairly similar issues with configure and m4. Both of their package systems seem to install autotools without installing all the dependencies that are actually required. The auto-tool-chain seems to hide error messages that might tell me what’s missing (like gcc!!). > > Is that a Heimdal problem? If it’s actually something missing, you could argue that it’s a (very serious!) autotools problem. In the real world, if you ever expect anyone to use a GIT snapshot and try out Heimdal, I think some useful error message is required. I haven’t decided if I blame the autotools packages for not having sufficient prerequisites, yet. <curmudgeon> Autotools have grown to the point where they are a bigger problem than the one they are supposed to solve. I think my recent experience suggests they are a significant source of fragility. New projects should think twice before using them. </curmudgeon> Excuse my grumpiness. >> I hadn’t planned on needing to debug things at this level, but I did want something that would work on a BeagleBone or Pi. >> >> Assuming I can spend some time on this, what would it take to make the latest version at least minimally usable? >> >> Is there no longer a build farm? > > There is no build farm. > >> Are we missing someone to apply patches? > > Nico, Viktor and I have been applying patches as we have time. > > We don't have a lot of time. Heimdal has no dedicated development or > release management resources at the moment. That said, we are doing our > best to move towards a release candidate as time permits. > > If there are problems on master, report them via GitHub with a > reproducible test case. Better yet, propose a fix. > > Jeffrey Altman Personal email. [email protected]