Discussion:
Failure trying to setup build robot for gnulib on Fedora/22.
John Malmberg
2017-06-08 13:21:29 UTC
Permalink
I am trying to set up a build robot to see if the VMS GNV packages is
good enough to run to tests on GNULIB.

https://www.gnu.org/software/gnulib/manual/gnulib.html#Build-robot-for-gnulib

First issue found is what I reported earlier:
http://autobuild.josefsson.org/gnulib/ is not reachable.

I issued the command below and it failed on a Fedora/22 system with a
2.1 Ghz dual core CPU, 8 GB ram and a SATA hard drive with 200 G free.

Build steps are controlled by Jenkins 2.64 checking the gnulib repo once
a day.
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url git://git.savannah.gnu.org/gnulib.git #
timeout=10
Fetching upstream changes from git://git.savannah.gnu.org/gnulib.git
git --version # timeout=10
git fetch --tags --progress git://git.savannah.gnu.org/gnulib.git
+refs/heads/*:refs/remotes/origin/* --depth=1
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision b55a085bbebf867ee1a8b0f9dd088a65508c6a22
(refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f b55a085bbebf867ee1a8b0f9dd088a65508c6a22
git rev-list b55a085bbebf867ee1a8b0f9dd088a65508c6a22 # timeout=10
Cleaning workspace
git rev-parse --verify HEAD # timeout=10
Resetting working tree
git reset --hard # timeout=10
git clean -fdx # timeout=10
[master] $ /bin/bash /tmp/jenkins6710415235745568817.sh
./gnulib-tool --create-megatestdir --with-tests \
--dir=/home/jeeves/mirrors/gnu/gnulib/gnulib
Module list with included dependencies (indented):
_Exit
_Exit-tests
...
3 hours, 38 minutes later
...
Module list with included dependencies (indented):
non-recursive-gnulib-prefix-hack
File list:
build-aux/prefix-gnulib-mk
lib/dummy.c
m4/00gnulib.m4
m4/gnulib-common.m4
m4/non-recursive-gnulib-prefix-hack.m4
m4/onceonly.m4
executing aclocal -I glm4
executing autoconf
executing autoheader
executing automake --add-missing --copy
configure.ac:112: error: required directory ./lib does not exist
configure.ac:8: installing 'build-aux/compile'
configure.ac:4: installing 'build-aux/install-sh'
configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'


Other issues:

It states with the machine has GNU development tools on it is needed.
I could not find exactly what tools that it needed.

The obvious ones from web searches were:
gcc, git, make, autoconf, automake, libtool.

After 1 hour 54 minutes, I discovered it needed bison.

Cleaning the work directory and re-running, it took 2 hours and 6
minutes to discover it needed "autopoint" from gettext-devel package.

Cleaning the work directory and re-running, it took 2 hours and 22
minutes to discover it needs "gperf" installed.

Which got me to the point above.

Am I doing something wrong? I am just following the web page.

Can the web page be updated to give a complete list of tools needed?

Are there any tools that I may still be missing? This is basically a
Fedora/22 workstation with the above tools and Jenkins installed.

Can the web page be updated to give an estimate of how long each step
that takes more than a few minutes on at least one type of CPU / memory
combination?

Regards,
-John
Eric Blake
2017-06-08 13:34:19 UTC
Permalink
Post by John Malmberg
I issued the command below and it failed on a Fedora/22 system with a
You _do_ realize that Fedora 22 is unsupported upstream, and is probably
lacking in security patches that you would otherwise get by upgrading to
a version of Fedora whose lifetime has not expired?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
John Malmberg
2017-06-08 13:46:37 UTC
Permalink
Post by Eric Blake
Post by John Malmberg
I issued the command below and it failed on a Fedora/22 system with a
You _do_ realize that Fedora 22 is unsupported upstream, and is probably
lacking in security patches that you would otherwise get by upgrading to
a version of Fedora whose lifetime has not expired?
No I did not realize that. I will attempt an upgrade this evening.
That system is not directly connected to the internet.

I hope that NFS v2 is still present in Fedora 25 or I will have problems
with it serving to files to my VAX systems.

Regards,
-John
John E. Malmberg
2017-06-09 12:56:52 UTC
Permalink
Post by Eric Blake
Post by John Malmberg
I issued the command below and it failed on a Fedora/22 system with a
You _do_ realize that Fedora 22 is unsupported upstream, and is probably
lacking in security patches that you would otherwise get by upgrading to
a version of Fedora whose lifetime has not expired?
No I did not realize that. I will attempt an upgrade this evening. That
system is not directly connected to the internet.
I hope that NFS v2 is still present in Fedora 25 or I will have problems
with it serving to files to my VAX systems.
Fedora 23 Upgrade. NFS v2/v3 mounts work for VAX/VMS 7.3 through
IA64/VMS 8.4

Fedora 24 Upgrade. Same.

Fedora 25 Upgrade. VMS will not mount the NFS export on any version.
Only thing found in messages.log is a successful connect message
immediately followed by a successful disconnect message.

Ubuntu 14.04 system can mount the same NFS export with v2 or v3, so
everything should be configured properly.

sudo dnf downgrade nfs-utils to nfs-utils-1:1.3.4-1.rc2.fc25.x86_64 and
VMS is mounting the NFS shares again.

Next is to fix what should be some minor issues where the Jenkins build
agent ssh keys are being rejected, and I can get back to trying to see
how much of the gnulib stuff works with VMS GNV.

Regards,
-John
Paul Eggert
2017-06-09 17:08:51 UTC
Permalink
Post by John E. Malmberg
Fedora 25 Upgrade. VMS will not mount the NFS export on any version.
Does the VMS client mount over UDP only? If so, that is probably the
problem. Recent nfs-utils (as used in Fedora 25) disabled UDP support by
default, as the major NFS clients have supported TCP for many years; see:

https://patchwork.kernel.org/patch/9591703/

Try editing /etc/sysconfig/nfs and adding -u to RPCNFSDARGS; that way
you should not have to mess with downgrading nfs-utils. See rpc.nfsd(8).

Alternatively, perhaps you can get your VMS client to use TCP. That
would probably be better, if it works.
John E. Malmberg
2017-06-10 02:10:42 UTC
Permalink
Post by Paul Eggert
Post by John E. Malmberg
Fedora 25 Upgrade. VMS will not mount the NFS export on any version.
Does the VMS client mount over UDP only? If so, that is probably the
problem. Recent nfs-utils (as used in Fedora 25) disabled UDP support by
https://patchwork.kernel.org/patch/9591703/
Try editing /etc/sysconfig/nfs and adding -u to RPCNFSDARGS; that way
you should not have to mess with downgrading nfs-utils. See rpc.nfsd(8).
I tried "-V 2 -u" and the nfs server would not start.

I then tried "--udp -V 2" and the nfs server restarted and everything is
working with the newer nfs-utils.
Post by Paul Eggert
Alternatively, perhaps you can get your VMS client to use TCP. That
would probably be better, if it works.
The TCP/IP with VMS 8.4 and later allow using TCP to mount NFS exports.

The TCP/IP with VMS 7.3/VAX requires NFS V2 and UDP.

Thanks,
-John
Bruno Haible
2017-06-08 15:40:29 UTC
Permalink
Hi John,
Post by John Malmberg
[master] $ /bin/bash /tmp/jenkins6710415235745568817.sh
./gnulib-tool --create-megatestdir --with-tests \
--dir=/home/jeeves/mirrors/gnu/gnulib/gnulib
_Exit
_Exit-tests
...
3 hours, 38 minutes later
Yes, --create-megatestdir is slow and produces a huge number
of configure scripts. For interactive use, everyone prefers --create-testdir
- but you explicitly cite doc/build-automation.texi.
Post by John Malmberg
It states with the machine has GNU development tools on it is needed.
I could not find exactly what tools that it needed.
gcc, git, make, autoconf, automake, libtool.
After 1 hour 54 minutes, I discovered it needed bison.
Cleaning the work directory and re-running, it took 2 hours and 6
minutes to discover it needed "autopoint" from gettext-devel package.
Cleaning the work directory and re-running, it took 2 hours and 22
minutes to discover it needs "gperf" installed.
These requirements are listed in the file DEPENDENCIES.
Post by John Malmberg
Can the web page be updated to give a complete list of tools needed?
Feel free to submit a patch to doc/build-automation.texi that references
DEPENDENCIES ...
Post by John Malmberg
Can the web page be updated to give an estimate of how long each step
that takes more than a few minutes on at least one type of CPU / memory
combination?
On Cygwin the times would be very different than on Linux.

Bruno
Paul Eggert
2017-06-08 22:28:48 UTC
Permalink
Post by Bruno Haible
Feel free to submit a patch to doc/build-automation.texi that references
DEPENDENCIES ...
I gave a shot at patching the documentation. The new version is at:

https://www.gnu.org/software/gnulib/manual/gnulib.html#Building-gnulib

I did find one thing that's not in DEPENDENCIES: Perl. I don't know what
Perl version we're assuming, though.
John E. Malmberg
2017-06-12 13:05:26 UTC
Permalink
Post by Paul Eggert
Post by Bruno Haible
Feel free to submit a patch to doc/build-automation.texi that references
DEPENDENCIES ...
https://www.gnu.org/software/gnulib/manual/gnulib.html#Building-gnulib
I did find one thing that's not in DEPENDENCIES: Perl. I don't know what
Perl version we're assuming, though.
Looks good for me to continue on.

I have perl 5.20 installed, and can easily upgrade to perl 5.24 if needed.

Perl on VMS currently supports shebangs in scripts. With out that, it
assumes that it running the DCL interpreter, not bash.

I have --create-testdir run and am now going to see how much of
do-autobuild works on VMS.

Thanks,
-John

Loading...