Can't build RPM of xfstests

...

=== rpm ===
-e'/^BuildRoot: *$/d' \
/usr/bin/rpmbuild -ba --rcfile ./rpm-4.rc xfstests.spec
error: File /root/rpmbuild/SOURCES/xfstests-1.1.1.src.tar.gz: No such file or directory
gmake[1]: *** [dist] Error 1

I've never tried to build xfstests packages, so I'd make the
assumption that the package build infrastructure is broken and needs
fixing. That's looking for the tarball in the wrong place. My naive
reading of that is rpmbuild is expecting to run as root, not as a
jenkins user....
Eric, you're the local RPM expert - any ideas?
FWIW, I'll take whatever patches you guys come up with that make it
build rpms properly. ;)

xfstests rpms have just never been a priority for me. I run it just fine out
of a checked-out git repo, and it doesn't require installation; on the other
hand, making it palatable for a proper FHS-compliant distro package would
require a fair bit of restructuring beyond just the packaging scripts.

And... I honestly have no idea how the Makepkgs stuff is supposed to work.

I've never been a fan of upstream containing packaging bits anyway; different
distros have different requirements, and the Makepkgs script has always seemed
weird. RPM/specfiles are supposed to drive the build - the build isn't supposed
to drive rpm. I think it'd be best to make a distro-specific specfile which knows how
to handle an xfstests tarball. Trying to reverse engineer Makepkgs doesn't sound
fun to me; rpmbuild knows how to do this stuff. Dropping a generic RPM specfile
into the top level dir would probably be enough to get it off the ground even if
it doesn't conform to any particular distro's packaging rules.

I think it's up to those who want rpms to dig into this, for now. Dumping all
files into /opt/xfstests is probably simplest, since FHS-compliance is probably a
long ways off.

-Eric

Greg Freemyer

2014-10-20 11:55:08 UTC

...

=== rpm ===
-e'/^BuildRoot: *$/d' \

xfstests.spec

/usr/bin/rpmbuild -ba --rcfile ./rpm-4.rc xfstests.spec
error: File /root/rpmbuild/SOURCES/xfstests-1.1.1.src.tar.gz: No

such file or directory

gmake[1]: *** [dist] Error 1

I've never tried to build xfstests packages, so I'd make the
assumption that the package build infrastructure is broken and needs
fixing. That's looking for the tarball in the wrong place. My naive
reading of that is rpmbuild is expecting to run as root, not as a
jenkins user....
Eric, you're the local RPM expert - any ideas?
FWIW, I'll take whatever patches you guys come up with that make it
build rpms properly. ;)

xfstests rpms have just never been a priority for me. I run it just fine out
of a checked-out git repo, and it doesn't require installation; on the other
hand, making it palatable for a proper FHS-compliant distro package would
require a fair bit of restructuring beyond just the packaging scripts.
And... I honestly have no idea how the Makepkgs stuff is supposed to work.
I've never been a fan of upstream containing packaging bits anyway; different
distros have different requirements, and the Makepkgs script has always seemed
weird. RPM/specfiles are supposed to drive the build - the build isn't supposed
to drive rpm. I think it'd be best to make a distro-specific specfile which knows how
to handle an xfstests tarball. Trying to reverse engineer Makepkgs doesn't sound
fun to me; rpmbuild knows how to do this stuff. Dropping a generic RPM specfile
into the top level dir would probably be enough to get it off the ground even if
it doesn't conform to any particular distro's packaging rules.
I think it's up to those who want rpms to dig into this, for now.
Dumping all
files into /opt/xfstests is probably simplest, since FHS-compliance is probably a
long ways off.
-Eric

Opensuse is building rpms of 1.1.1 so the build infrastructure isn't too badly broken. I don't know if they are following FHS, but I doubt they use /opt.

The opensuse package/specfile can be found at: https://build.opensuse.org/package/show/filesystems/xfstests

The rpms including the source rpm can be downloaded from:
http://software.opensuse.org/download.html?project=filesystems&package=xfstests

Note the specfile applies a patch to change the install aspect of the tarball immediately after untar'ing it.

I don't maintain that so I don't know why the patch is needed.

Greg

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Eric Sandeen

2014-10-20 13:54:47 UTC

Post by Greg Freemyer
Opensuse is building rpms of 1.1.1 so the build infrastructure isn't
too badly broken. I don't know if they are following FHS, but I
doubt they use /opt.

The build works fine, it's the "Makepkgs" that I think is a bit odd,
at least for RPM packaging.

Also, if we really want to encourage packaging, we should probably start
sticking official version numbers on it. "1.1.1" was tagged in Dec 2012,
and there have been no "releases" since.

Post by Greg Freemyer
https://build.opensuse.org/package/show/filesystems/xfstests
http://software.opensuse.org/download.html?project=filesystems&package=xfstests
Note the specfile applies a patch to change the install aspect of
the tarball immediately after untar'ing it.
I don't maintain that so I don't know why the patch is needed.

Ok, cool, I'll take a look at the specfile & patch. I had also packaged
it up for our internal QA use long ago, and had to make a few changes
as well.

-Eric

Dave Chinner

2014-10-20 23:08:40 UTC

Post by Greg Freemyer
Opensuse is building rpms of 1.1.1 so the build infrastructure isn't
too badly broken. I don't know if they are following FHS, but I
doubt they use /opt.

The build works fine, it's the "Makepkgs" that I think is a bit odd,
at least for RPM packaging.

It's just odd, regardless of what it is packaging.

Post by Eric Sandeen
Also, if we really want to encourage packaging, we should probably start
sticking official version numbers on it. "1.1.1" was tagged in Dec 2012,
and there have been no "releases" since.

There are more recent tags than that. There were some linux-v3.[6-8]
tags added when kernels v3.[6-8] we released. Those tags are
basically meaningless from a release perspective, though.

As it is, for the purpose of the discussion I'll argue that we don't
need official release versions or tarballs and that anyone who needs
packages for xfstests is Doing it Wrong(tm). Realistically, the
current head commit ID works just fine as a release version and so I
don't think we don't need tarballs or released versions of xfstests.
xfstests is developer rather than end user focussed and so it is
assumed that you understand git if you have a need for running
xfstests...

i.e. this works as a test machine deployment method and is easily
scriptable and deployable on test machines:

# <install prereq packages>
# cd /opt
# git clone <xfstests git repo on build server>
# cd xfstests
# make
# <grab config file from build server>
# ./check -g auto

And with that, there is no need for packaging....

That said, xfstests needs to be flexible so it can operate in all
sorts of different environments, so how I do things really doesn't
matter that much. If people really need xfstests to build RPMs so
they can deploy RPMs, then like I said I'll take patches to make
that work...

Cheers,

Dave.

--
Dave Chinner
***@fromorbit.com

Greg Freemyer

2014-10-20 23:31:50 UTC

--
Greg Freemyer

Post by Greg Freemyer
Opensuse is building rpms of 1.1.1 so the build infrastructure isn't
too badly broken. I don't know if they are following FHS, but I
doubt they use /opt.

The build works fine, it's the "Makepkgs" that I think is a bit odd,
at least for RPM packaging.

It's just odd, regardless of what it is packaging.

A potential use case with openSUSE and why I "think" they packaged it
is to include a subset of xfstest in there automated testing.

As of the last 9 months openSUSE's "factory" release has adopted a
rolling release mechanism similar to rawhide, but possibly a little
more reliable.

Many submissions to factory (the rawhide equivalent) are pushed
through a ring of automated QA tests.

Separately on a daily basis the entire current factory release is
pushed through a series of automated QA tests.

If all QA tests pass, then a full factory snapshot is automatically
released for end-user incorporation.

My hope is that xfstests is packaged by openSUSE so it can easily be
incorporated into that series of automated tests.

If they are not yet doing that, then having xfstests packaged
simplifies the future incorporation of xfstests into the auto-QA
cycle.

Overview: https://openqa.opensuse.org/tests/

Table of automated test results:
https://openqa.opensuse.org/tests/

Notice for example that ext4 is a testsuite selection in the testsuite
pull down. I assume that testsuite uses xfstests to exercise ext4
prior to an automated release of factory.

The 2014-10-17 build of a couple days ago is an example of a build
that failed the ext4 testsuite:
https://openqa.opensuse.org/tests/27955

The 2014-10-18 build on the otherhand worked:
https://openqa.opensuse.org/tests/28263

It is interesting to look through the various screen shots captured by
the automated test system.

I don't see automated tests for xfs or btrfs which is a surprise since
both of them are default filesystem choices for factory. (btrfs is
the default choice for / and xfs is the default for /home).

Note: openSUSE still will do formal releases and the next one is
openSUSE 13.2 due out next month. 13.2 should be getting lots of
manual testing in addition to the automated QA testing.

Greg

Dave Chinner

2014-10-20 23:57:19 UTC

Post by Greg Freemyer
--
Greg Freemyer

Post by Greg Freemyer
Opensuse is building rpms of 1.1.1 so the build infrastructure isn't
too badly broken. I don't know if they are following FHS, but I
doubt they use /opt.

The build works fine, it's the "Makepkgs" that I think is a bit odd,
at least for RPM packaging.

It's just odd, regardless of what it is packaging.

A potential use case with openSUSE and why I "think" they packaged it
is to include a subset of xfstest in there automated testing.

Sure - i'm just pointing out that you don't need RPM to do that -
git it just as good for deploying automated testing infrastructure
;)

....

Post by Greg Freemyer
Notice for example that ext4 is a testsuite selection in the testsuite
pull down. I assume that testsuite uses xfstests to exercise ext4
prior to an automated release of factory.
The 2014-10-17 build of a couple days ago is an example of a build
https://openqa.opensuse.org/tests/27955

That doesn't appear to anything to do with xfstests. It appears to
be a "can we install opensuse" installer test that happens to be run
on ext4. i.e. it's really product level testing (i.e. whether the
opensuse build worked) not whether the filesystem works as it's
supposed to.

Post by Greg Freemyer
I don't see automated tests for xfs or btrfs which is a surprise since
both of them are default filesystem choices for factory. (btrfs is
the default choice for / and xfs is the default for /home).

Seeing as it's not actually doing filesystem level testing, it
probably doesn't matter at all.

Cheers,

Dave.

--
Dave Chinner
***@fromorbit.com

Eryu Guan

2014-10-21 03:15:43 UTC

Post by Greg Freemyer
Opensuse is building rpms of 1.1.1 so the build infrastructure isn't
too badly broken. I don't know if they are following FHS, but I
doubt they use /opt.

The build works fine, it's the "Makepkgs" that I think is a bit odd,
at least for RPM packaging.
Also, if we really want to encourage packaging, we should probably start
sticking official version numbers on it. "1.1.1" was tagged in Dec 2012,
and there have been no "releases" since.

Ok, cool, I'll take a look at the specfile & patch. I had also packaged
it up for our internal QA use long ago, and had to make a few changes
as well.

This is the spec file used internally by Red Hat, just for your reference

Thanks,
Eryu

Name: xfstests
Version: 20141014
Release: 1.git
Summary: xfs qa tests

Group: misc
License: GPL
URL: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git
Source0: $RPM_BUILD_ROOT/SOURCES/xfstests-dev.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires: autoconf, libtool, e2fsprogs-devel, xfsprogs-devel
BuildRequires: libacl-devel, libattr-devel, libaio-devel
Requires: bash, perl, acl, attr, bind-utils
Requires: bc, indent, quota, xfsprogs

%description
The xfsqa test available at http://git.kernel.org/?p=fs/xfs/xfstests-dev.git or http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfstests.git

%prep
%setup -q -n xfstests-dev

%build
autoheader
autoconf
%configure
make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
# Dirty workaround, xfstets won't build if these two directories do not exist...
mkdir -p /var/lib/xfstests/{ltp,src}

make DIST_ROOT=$RPM_BUILD_ROOT install

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc README
/var/lib/xfstests

%changelog
......

Post by Eric Sandeen
-Eric
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

Eric Sandeen

2014-10-20 23:23:52 UTC

Post by Greg Freemyer

...

=== rpm ===
-e'/^BuildRoot: *$/d' \

xfstests.spec

/usr/bin/rpmbuild -ba --rcfile ./rpm-4.rc xfstests.spec
error: File /root/rpmbuild/SOURCES/xfstests-1.1.1.src.tar.gz: No

such file or directory