| Message ID | CAH2r5mvi2LijxWia2sCf+em7rfPtBn_fg6WKU=aftVUTuzXMgw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Nov 13, 2014 at 05:20:34PM -0800, Steve French wrote: > On Thu, Nov 13, 2014 at 6:02 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Thu, Nov 13, 2014 at 05:38:53PM -0600, Steve French wrote: > >> To get xfstests to build on Ubuntu 14.10 and run (after adding various > >> packages I could get all but 11 of the tests to build and run) I had > >> to install the following packages: > >> > >> sudo apt-get install xfslibs-dev uuid-dev libtool e2fsprogs automake > >> libuuid1 libuuidm-ocaml-dev attr libattr1-dev libacl1-dev libaio-dev > >> xfsprogs libgdbm-dev gawk fio dbench > > > > Documentation patch for the README file? > > > > Cheers, > > > > Dave. > > Patch attached There are two copies of it in this email - one pasted in the middle of the rest of the quoted email text and so is whitespace damaged, the other as a base64 encoded attachment so can't be quoted and replied to easily. In future, can you send patches as separate emails according to: https://www.kernel.org/doc/Documentation/email-clients.txt > [PATCH] common: update README to list build dependencies > > Add sample list of packages (dependencies) required to build XFSTESTS > and add a step to the instructions to mention creating the test > user needed for some of the ACL tests. > > Signed-off-by: Steve French <smfrench@gmail.com> > --- > README | 6 ++++++ > > > diff --git a/README b/README > index 8a362bd..8db7efe 100644 > --- a/README > +++ b/README > @@ -4,8 +4,14 @@ _______________________ > > Building Linux: > - cd into the xfstests directory > + - install prerequisite packages > + For example, for Ubuntu: > + "sudo apt-get install xfslibs-dev uuid-dev libtool e2fsprogs > + automake gcc libuuid1 libuuidm-ocaml-dev attr libattr1-dev ^^^^^^^^^^^^^^^^^^ What in xfstests is dependent on ocaml? Cheers, Dave.
On Mon, Nov 17, 2014 at 2:38 PM, Dave Chinner <david@fromorbit.com> wrote: > the other as a base64 encoded attachment so can't be quoted and > replied to easily. In future, can you send patches as separate > emails according to: Yes. WIll do. It is a pain in test VMs to setup git with gmail two phase authentication but doable if I set it up to send mail from a different host. >> Building Linux: >> - cd into the xfstests directory >> + - install prerequisite packages >> + For example, for Ubuntu: >> + "sudo apt-get install xfslibs-dev uuid-dev libtool e2fsprogs >> + automake gcc libuuid1 libuuidm-ocaml-dev attr libattr1-dev > ^^^^^^^^^^^^^^^^^^ > > What in xfstests is dependent on ocaml? That libuuidm-ocaml-dev looks unneeded now (I ended up pulling in one of the tools a different way so whatever that pulled in looks superfluous now) - in an earlier try at this I built a few of the tools. But there is one missing. I missed in the cut-and-pastes an obvious very important dependency when I was transcribing the dependency list - "quota" I will add that to the list and remove the libuuidm-ocaml-dev off now that I have confirmed the dependencies list again today on a fresh Ubuntu install.
On Mon, Nov 17, 2014 at 08:35:39PM -0600, Steve French wrote: > On Mon, Nov 17, 2014 at 2:38 PM, Dave Chinner <david@fromorbit.com> wrote: > > > the other as a base64 encoded attachment so can't be quoted and > > replied to easily. In future, can you send patches as separate > > emails according to: > > Yes. WIll do. It is a pain in test VMs to setup git with gmail two > phase authentication > but doable if I set it up to send mail from a different host. No need for that. Keep the xfstests source tree on your laptop/workstation and do all your edits there. When you've done that, simply rsync the tree to the test VM(s) and run "make; ./check ..." from the shell you are running in the test VM. That way you can manage the code multiple test VMs run from a single source tree, all in one location, and you don't have to worry about setting up for mail, backups, losing changes because a test machine crash ate your recent changes, accidentally sending changes are root, etc... Cheers, Dave.
On Wed, Nov 19, 2014 at 07:28:18AM +1100, Dave Chinner wrote: > No need for that. Keep the xfstests source tree on your > laptop/workstation and do all your edits there. When you've done > that, simply rsync the tree to the test VM(s) and run "make; ./check > ..." from the shell you are running in the test VM. > > That way you can manage the code multiple test VMs run from a single > source tree, all in one location, and you don't have to worry about > setting up for mail, backups, losing changes because a test machine > crash ate your recent changes, accidentally sending changes are > root, etc... Or commit them to a local git branch that you can pull from the VMs instead of the rsync. The effect is the same, though. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 17, 2014 at 08:35:39PM -0600, Steve French wrote: > > Yes. WIll do. It is a pain in test VMs to setup git with gmail two > phase authentication > but doable if I set it up to send mail from a different host. There are lots of ways to skin a cat, but I just simply build xfstests in my standard development environment, and then either create a completely new test VM image from scratch, which doesn't take _that_ long: <tytso@closure> {/u1/xfstests-bld/build-32/kvm-xfstests/test-appliance} 521% /usr/bin/time schroot -c sid -u root ./gen-image ... /tmp/root_fs.raw.7430: 9867/65536 files (0.0% non-contiguous), 66071/262144 blocks 65.23user 15.65system 1:25.65elapsed 94%CPU (0avgtext+0avgdata 11076maxresident)k 42inputs+970048outputs (0major+1528344minor)pagefaults 0swaps or I'll update the VM image from my build directory, which keeps the OS files the same and only updates the files in /root/xfstests: <tytso@closure> {/u1/xfstests-bld/build-32/kvm-xfstests/test-appliance} 523% /usr/bin/time schroot -c sid -u root -- ./gen-image --update ... 9.98user 1.65system 0:12.81elapsed 90%CPU (0avgtext+0avgdata 11644maxresident)k 4674inputs+178512outputs (0major+204070minor)pagefaults 0swaps The advantage of doing it that way is that I get replicable builds for my xfstest VM's, and it also helps keep them small (only 66 megs), which makes them easier to move around to different test servers. (I also like not being dependent on the version of xfslibs-dev that Ubuntu might have decided to ship, since a while back I was stuck on pretty ancient LTS versions due to corporate policy reasons, and there were a few tests that required the latest versions of xfsprogs/xfslibs in order to build and run. So that's why I use a completely hermetic build in my infrastructure, which can be found in my xfstests-bld git tree if you want to give it a try.) Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From 1822e733684f031b13392782e2a7eef1ab102d17 Mon Sep 17 00:00:00 2001 From: Steve French <smfrench@gmail.com> Date: Thu, 13 Nov 2014 17:07:27 -0800 Subject: [PATCH] common: update README to list build dependencies Add sample list of packages (dependencies) required to build XFSTESTS and add a step to the instructions to mention creating the test user needed for some of the ACL tests. Signed-off-by: Steve French <smfrench@gmail.com> --- README | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README b/README index 8a362bd..8db7efe 100644 --- a/README +++ b/README @@ -4,8 +4,14 @@ _______________________ Building Linux: - cd into the xfstests directory + - install prerequisite packages + For example, for Ubuntu: + "sudo apt-get install xfslibs-dev uuid-dev libtool e2fsprogs + automake gcc libuuid1 libuuidm-ocaml-dev attr libattr1-dev + libacl1-dev libaio-dev xfsprogs libgdbm-dev gawk fio dbench" - run make - run make install + - create fsgqa test user ("sudo useradd fsgqa") Building IRIX: - cd into the xfstests directory -- 2.1.0