Noise in logs on arch Linux

garazdawi commented 2 weeks ago

The bug

There seems to be some noise in the logs when doing package detection on arch. See the discussion here: https://elixirforum.com/t/installing-erlang-part-with-asdf-automake-error-configure-ac-is-required

The printouts to the shell are this:

==> Checking whether specified Elixir release exists...
==> Downloading 1.16.0-otp-26 to /home/alexey/.asdf/downloads/elixir/1.16.0-otp-26/elixir-precompiled-1.16.0-otp-26.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 7027k  100 7027k    0     0  8610k      0 --:--:-- --:--:-- --:--:-- 8612k
==> Copying release into place
Downloading kerl...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 82830  100 82830    0     0   226k      0 --:--:-- --:--:-- --:--:--  226k
ERROR: 'asdf_26.2.1' is not a kerl-managed Erlang/OTP installation.
ERROR: no build named 'asdf_26.2.1'!
Downloading (from GitHub) Erlang/OTP 26.2.1 to /home/alexey/.asdf/downloads/erlang/26.2.1...
Extracting source code for normal build...
Building (normal) Erlang/OTP 26.2.1 (asdf_26.2.1); please wait...
Initializing (build) log file at /home/alexey/.asdf/plugins/erlang/kerl-home/builds/asdf_26.2.1/otp_build_26.2.1.log.
automake: error: 'configure.ac' is required
autoconf: error: no input file

Where the last two lines are not actually errors (I think), but just noise from when testing if automake and autoconf exist.

BTW why do you check for automake? Nothing in Erlang has ever used automake, only autoconf and make/gmake...

Software versions

Operating System: arch Linux
Erlang/OTP: 26
kerl: Not sure...

How to replicate

I've not reproduced it my self, but I imagine you just run kerl build in arch Linux.

Expected behaviour

No printouts about automake or autoconf!

paulo-ferraz-oliveira commented 2 weeks ago

Fwiw, 38e5fec added automake. I'm not sure @jadeallenx would remember why it was done (it's more than 7 years ago), but it's never raised issues before, so it was kept. 😄

On the probes (I guess that's what you're talking about) I can check why it would print out that stuff (we surely don't want misleading noise in kerl) since I implemented it (but was under the impression I redirected stderr to /dev/null; maybe it also needs stdout to dev/null 😆)...

paulo-ferraz-oliveira commented 2 weeks ago

I don't have Arch Linux at hand (and using an ARM, so potentially not easy to install), but am curious if KERL_CHECK_BUILD_PACKAGES=no kerl ... exhibits the same output.

Edit: on Ubuntu, the probe code is dpkg-query -Wf'${db:Status-abbrev}' "autoconf" 2>/dev/null | \grep -q '^i', which will return 1 if autoconf is not present, but output nothing.

paulo-ferraz-oliveira commented 2 weeks ago

With the above:

we could/should remove automake from the probes, as it's not an Erlang/OTP installation requirement
I don't think the probe itself outputs the noise, but maybe it's something else

I'll add a help_wanted label and we can leave this hanging for a while...

jadeallenx commented 2 weeks ago

OK. Yeah maybe this is just cruft but I seem to recall that autoconf required automake at some point? At least I have recollection that autoconf deb mandated automake. Probably no longer true ? Or maybe I am just misremembering entirely. But I do remember there was a time when OTP builds (maybe back when dinosaurs roamed the earth) needed both autoconf and automake.

garazdawi commented 2 weeks ago

As Erlang has not required autoconf since version 24, it might be time to drop them as a dependency alltogether? Though maybe it is nice to wait a couple of more releases as 23 has "only" been out of support for 1 year.

paulo-ferraz-oliveira commented 2 weeks ago

The probes are a best-effort implementation. They try to predict what'll be necessary, but only warn about the missing stuff, they don't stop kerl execution. At the same time there's also an option to not warn. We can wait, sure; though I'm still not sure what to do about the other output that doesn't seem to come from kerl, which means we'd require external help.

kerl / kerl