Patch for building multi-arch RPMs with mock

Attached patch enables building for multiple architectures and multiple distros using mock (RedHat based distros).

Building RPMs for SuSe should still work via rpmbuild.

Chosen minimal version of libevent works and should be satisfied even in very old RH/SuSe distros.

Builds EL6-x86_64, Fedora 16 i386/x86_64 versions on Scientific Linux 6 (RHEL clone). Though in general it's recommended to use newer distro as build platform - build for F17 failed on SL6 due to unsupported new RPM features.

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/rpm packaging fedora milestone::Tor: 0.2.3.x-final owner::hiviah priority::medium resolution::implemented rhel rpm status::closed type::enhancement labels

Hm. Looks very plausible to me, but I don't know mock or rpmbuild at all. If some other RPM person could check this out too, I'd be glad to merge.

Trac:
Milestone: N/A to Tor: 0.2.3.x-final
Status: new to needs_review

Replying to nickm:

Not sure if any Tor developer knows rpm format spec (I don't know all the details either), but I could ask someone maintaining EPEL packages to check.

Mock is basically wrapper for rpmbuild that does chroot, then creates a copy of target build environment (libraries, etc) and finally builds using rpmbuild. The dependencies are added to .spec file so that mock will pull them into the chrooted environment, otherwise build fails.

I've created a Fedora 17 VM and tested the above patch. Works for building EL6, F17, F16, F15 (both x86_64 and i686), EL5 build fails due to some internal error (MD5 verification of unpacked cpio archive). Adding attachment (root.log) for later reference, error is at line 385.

Note: about 1-1.5 GB is required for one build per distro/arch combination, but it could grow since mock keeps cache.

Trac:
root.log

Error log for failed build for EL5 x86_64 (i686 encounters identical error)

Suggestion on maintaining tags (there was similar suggestion in trac, can't find it now):

I'd use the https://gitweb.torproject.org/rpm/tor.git for storing clone for building Tor RPMs. The main reason is to avoid waiting for new git tag in case RPM build breaks for some trivial bug in .spec file. I've created a sample how it'd look like to fix some current bugs - https://github.com/hiviah/tor-rpm/branches (branches for stable and alpha).

1. When tag tor-X.Y.Z is made in main tor repo, pull from the repo into rpm/tor.git (cron job)
2. If the RPMs build OK, party (cron job; human signs the package)
3. If RPM build fails, create a branch tor-X.Y.Z_rpmbranch
4. Put the fix into the branch
5. Tag the branch tor-X.Y.Z_rpm, sign the tag
6. Create RPMs
7. Add trac request to pull the fix into main tor.git

Reopening since I've found some other tiny issues in the build. I'll just fix all of them before marking this as needs_review again (a developer Suse agreed to do the review after that).

• _tor userid is not created properly upon RPM install (EL6, F17)

• .git subtree is packed in the tar.gz in rpm

• the EL5 build bug is caused by missing SHA-256 support - https://bugzilla.redhat.com/show_bug.cgi?id=490613

• coding style - remove unnecessary %if's in rpm .spec

• remove all obsolete information from the doc/tor-rpm-creation.txt (like using static libevent)

Trac:
Status: needs_review to accepted
Owner: marlowe to haviah

(When a patch exists but it needs changes, convention is to put it in state "needs_revision".)

Glad to see more attention to RPM packaging, btw!

Trac:
Status: accepted to needs_revision

Adding patch for cleaned Makefile.am so that .git subtree and other temporary files are skipped when creating tar.gz, which is in turn used to create (S)RPMs.

Starting fails on F17 (0.2.3.17-beta), caused by missing "_tor" user. Works fine on F16 and EL6 (user _tor is added).

(Trac note: not sure if I should add all the patches to this ticket or create child subticket for each. ATM seems to me that keeping them in single ticket is "cleaner" - all of them need to be applied for working RPM build and reviewer would have them at single place.)

Attaching workaround/fix patch for the EL5 build bug.

Trac:
0002-Cleanup-of-RPM-build-process-no-more-.git-in-tarball.patch

Trac:
0003-Workaround-for-building-EL5-RPMs-by-specifying-rpmbu.patch

Trac:
mock-libevent.patch

Attaching fix for creation of _tor user on F17. Previous updates of old patches were fix of of 'ticket 6034' -> 'ticket 6043' in the subject (oh the irony).

Trac:
0004-Fixed-creating-_tor-user-in-RPM-based-installs.patch

Trac:
0005-Fixes-beautification-of-RPM-spec.-Tiny-improvements-.patch

The 0005 is the last patch (the first one is mock-libevent.patch). The RPM building was also tested on OpenSuse 12.1 (adding to Fedora 16/17 and EL 5/6).

After this ticket is reviewed, I'd need some machine or VM under torproject.org's control where I could set up the build environment. Minimum disk space required is 20 GB, 30 GB would be ideal.

Packages would be built automatically whenever a signed tag is created in git, signing would be done manually.

Trac:
Status: needs_revision to needs_review

Changing owner for nick consistency.

Trac:
Owner: haviah to hiviah
Status: needs_review to assigned

Trac:
Status: assigned to needs_review

I reviewed the proposed changes and they seem OK to me.

Trac:
Username: stick
Status: needs_review to assigned
Owner: hiviah to haviah

Trac:
Username: stick
Owner: haviah to hiviah

Okay, it got a review, and it looks okay to me (from what little I know), and it seems to work for me (at least, "make dist-rpm" spits something out on my fedora 17 desktop.)

If there are lingering bugs, I don't know how to find them other than by merging and seeing what happens.

Merging to 0.2.3.x. Thanks!

Trac:
Status: assigned to closed
Resolution: N/A to implemented

closed

moved to tpo/core/rpm-package#6043 (closed)