Where does the Latest Version Work?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Where does the Latest Version Work?

Henry B (Hank) Hotz, CISSP-2
I can get Heimdal 1.6 to work with some fiddling. There doesn’t seem to be a 1.7 branch in GIT. The bleeding-edge version doesn’t seem to be usable.

Since I believe there are people on this list actually doing development on Heimdal, where are you doing it?

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!!).

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? Are we missing someone to apply patches?


Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where does the Latest Version Work?

Jeffrey Altman-2
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?

The master branch is in production at a number of sites.

> 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?

> 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



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where does the Latest Version Work?

Henry B (Hank) Hotz, CISSP-2

> On Aug 11, 2016, at 6:37 PM, Jeffrey Altman <[hidden email]> 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.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where does the Latest Version Work?

Måns Nilsson-3
Subject: Re: Where does the Latest Version Work? Date: Fri, Aug 12, 2016 at 01:59:56AM -0700 Quoting Henry B (Hank) Hotz, CISSP ([hidden email]):
>
> 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 will argue that grumpiness like this is a completely sane reaction
to Autotools problems. I was trying to build master on old Solaris with
GNU tools (including the Autotool sh^Huite) that were not exactly new. I
was drawn into a seriously deep Jules Verne -style rathole of circular
dependencies; and gave up about when a new libtool was needed to build
a new libtool. Because libtool and its brethren in the Auto* club were
too new to work with the current libtool. And building libtool would
not work without libtool.

No, this is not a Heimdal problem, /per se/, but if the toolsuite intended
to facilitate builds on various divergent POSIXly hw/sw combinations
is not in itself reasonably easy to bootstrap, there is something of a
chicken-and-egg problem that makes it necessary to be _very_ careful
with depending on too new releases of these tools if one is going to
benefit from these tools in a software package like Heimdal.

Also, the autotool maintainers would benefit a lot from actually
publishing a high-level bootstrapping guide.

</rant>


--
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Where's th' DAFFY DUCK EXHIBIT??

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where does the Latest Version Work?

Ken Hornstein
>I will argue that grumpiness like this is a completely sane reaction to
>Autotools problems. I was trying to build master on old Solaris with GNU
>tools (including the Autotool sh^Huite) that were not exactly new. I
>was drawn into a seriously deep Jules Verne -style rathole of circular
>dependencies; and gave up about when a new libtool was needed to build
>a new libtool. Because libtool and its brethren in the Auto* club were
>too new to work with the current libtool. And building libtool would not
>work without libtool.

While I am autotools neutral (I feel about Autotools the way Winston
Churchill felt about democracy), I want to point out something here.

Normally, end users (people who just build software) should not have
to run any of the Autotools suite.  The idea is that the distribution
will already have the generated scripts, so all you do is just run the
generated configure script.  The problem here is that since Heimdal
doesn't have a new release (see previous discussions) no one has built a
distribution in a while, and people who want to built from the git tree
(normally only developers) then have to run the Autotools suite.  (Some
people put the autotools-generated scripts under revision control, but
personally I think that's a bad idea).

But the situation has a relatively simple solution; you can run the
autotools on ANOTHER machine, and then build a distribution tarball
with "make dist"; that will make a distribution tarfile with everything
pre-generated so you don't need any of the Autotools suite.  (Heimdal,
it turns out, not only requires Autotools but a JSON perl module just to
generate the tar file).

Hm, it does seem like lib/hcrypto/Makefile.am references dllmain.c,
which was removed in 2013; maybe somebody should fix that?  I guess
no one has tried to run "make dist" since then.  But once you fix
that, "make dist" works fine.  If you ask nicely, I could even
email that to you (but I don't guarantee it would work, of course;
I see that people haven't been building distribution tar balls in
a long while.  Again, see previous discussions regarding lack of
Heimdal development resources).

>Also, the autotool maintainers would benefit a lot from actually
>publishing a high-level bootstrapping guide.

I do not know what your exact problem is, but I have installed all of
the Autotools from scratch and none of them need themselves to build.
Bootstrapping has never been a problem.

--Ken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Where does the Latest Version Work?

Russ Allbery-2
Ken Hornstein <[hidden email]> writes:

> Normally, end users (people who just build software) should not have to
> run any of the Autotools suite.  The idea is that the distribution will
> already have the generated scripts, so all you do is just run the
> generated configure script.  The problem here is that since Heimdal
> doesn't have a new release (see previous discussions) no one has built a
> distribution in a while, and people who want to built from the git tree
> (normally only developers) then have to run the Autotools suite.  (Some
> people put the autotools-generated scripts under revision control, but
> personally I think that's a bad idea).

> But the situation has a relatively simple solution; you can run the
> autotools on ANOTHER machine, and then build a distribution tarball with
> "make dist"; that will make a distribution tarfile with everything
> pre-generated so you don't need any of the Autotools suite.  (Heimdal,
> it turns out, not only requires Autotools but a JSON perl module just to
> generate the tar file).

Yeah, basically this comes back to the same (and well-known) problem that
Heimdal is long overdue for an actual release that people can just build
and use without having to understand the development model or how to work
with a Git clone.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Loading...