Pete Zaitcev was having trouble building HekaFS the way he (apparently) builds other things, which led to an email discussion about how those of us already working on HekaFS currently build. With Pete’s permission – at his urging, in fact – here’s the scoop.
===
I can’t speak for Kaleb (or Edward) but my work flow is generally
something like this:
* Make changes on my desktop where I have a nice cscope setup etc.
* Rsync to build/test machine.
* Go into …/cloudfs/packaging.
* “make fedora” or “make gluster” as appropriate.
* Go into …/rpmbuild.
* “rpm –rebuild SRPMS/hekafs…”
* “yum reinstall –nogpgcheck RPMS/x86_64/hekafs…”
It’s a tiny package, so the whole cycle still takes practically no
time and it avoids most forms of inconsistency or rpm breakage. It
also allows me to deal with the differences between the Gluster and
Fedora packaging easily, which is important because I have to switch
between the two almost daily.
> If you write it somewhere, it would be appreciated. In particular,
> suppose you want to change something. Do you make changes to the git
> tree, or to the unpackage (rpmbuild -bp) tree? If the first, do you
> run the whole gauntlet in order to test the results? If the second,
> how do you scatter the changes back into the git (the pathnames are
> all different and not just having a different prefix)?
Sometimes while I’m debugging I make changes in …/cloudfs on the
build/test machine and rsync back, but I’ve been burned too many times
by making and then losing changes in …/rpmbuild/BUILD to do that any
more.
Can you clarify how this applies to the Rawhide package of HekaFS? Specifically this:
http://mirrors.kernel.org/fedora/development/rawhide/source/SRPMS/hekafs-0.7-10.fc17.src.rpm
Let’s say we already rolled glusterfs 3.2.2 and have it installed. Typically I would just rpmbuild -a hekafs.spec, but I wind up with this:
config.status: executing libtool commands
+ /usr/bin/make
/usr/bin/make all-recursive
make[1]: Entering directory `/root/rpmbuild/BUILD/hekafs-0.7′
Making all in crypt
make[2]: Entering directory `/root/rpmbuild/BUILD/hekafs-0.7/crypt’
/bin/sh ../libtool –tag=CC –mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -fPIC -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Wall -DGF_LINUX_HOST_OS -iquote/usr/include/glusterfs -iquote/usr/include/glusterfs/rpc -iquote/usr/include/glusterfs/server -shared -nostartfiles -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic -MT crypt.lo -MD -MP -MF .deps/crypt.Tpo -c -o crypt.lo crypt.c
mv -f .deps/crypt.Tpo .deps/crypt.Plo
mv: cannot stat `.deps/crypt.Tpo’: No such file or directory
make[2]: *** [crypt.lo] Error 1
make[2]: Leaving directory `/root/rpmbuild/BUILD/hekafs-0.7/crypt’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/hekafs-0.7′
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.7WgtUh (%build)
Sorry that’s glusterfs 3.2.3.
https://bugzilla.redhat.com/show_bug.cgi?id=736345
IIRC, that happens because some of the autofubar-generated files are being put into the SRPM, which they shouldn’t be, leaving things in a state that “rpmbuild -a” can’t deal with. I’m not the expert on packaging, though. For the quickest response, tracking etc. I’d suggest filing a bug on http://bugzilla.redhat.com – product=Fedora, component=hekafs. That way Kaleb will see it and hopefully provide a solution or workaround. If it were me, I’d unpack the SRPM, search and destroy any autofubar leftovers, and then pack it back up again.
OK, scratch that. I was unable to reproduce the problem using either the Fedora or Gluster RPMs for GlusterFS. RPM 4.8.0 wouldn’t even accept “-a” as a command. The only way I could reproduce the problem was to use rpmbuild’s “–nodeps” option to attempt a build despite not having installed glusterfs-devel on which it depends. Then I got exactly the same symptom you describe, so I guess I’m going to need a bit more info about *exactly* what you were attempting – e.g. what Fedora/CentOS version you were really using, where you got the RPMs, etc.
I’ve always been REALLY leery of having RPM anywhere near a development process. RPM is for packaging… usually for packaging the finished project.
I guess if a development change needs to go out to multiple machines, though, maybe RPM makes sense.
For this kind of software, even debugging changes typically have to go out to many machines.