Opened 8 years ago

Closed 3 years ago

#5205 closed project (invalid)

rpm package building

Reported by: ioerror Owned by: marlowe
Priority: Medium Milestone:
Component: Core Tor/RPM packaging Version:
Severity: Normal Keywords:
Cc: erinn, mikeperry, phobos, arma, marlowe@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need someone to do the following:
0) maintain RPM spec files in a git repo
1) automate building RPMs with something (buildbot?)
2) test the packages built; if problems, return to 0)
3) allow users to use these automated packages

I suggest marlowe, if he's up for it.

Child Tickets

Change History (20)

comment:1 Changed 8 years ago by marlowe

Cc: marlowe@… added

I hereby volunteer. I will be in and out until first week of March, but will be checking email. The spec is already part of the git repo if I remember correctly.

comment:2 Changed 8 years ago by ioerror

Cc: sebastian added

How do you feel about having a new git repo, just for rpms and you being the master of said git repo?

comment:3 Changed 8 years ago by marlowe

Sounds good to me. Will the spec file no longer be included in the tor source tarball?

comment:4 Changed 8 years ago by Sebastian

This would be entirely up to you. If there's just one file and you don't really need to upgrade it often, it might make more sense to keep it with Tor, but if you expect it to become a lot of files or to require a lot of changes, then having it separate might be useful. The latter has the disadvantage of making it harder for others to make an rpm build, of course, while the former has the disadvantage that we can't change the spec file for version X after version X got tagged.

comment:5 Changed 8 years ago by marlowe

Let me consult with erinn, but I don't think we will need a separate git repo. The rpm shouldn't include any files which wouldn't be included in the source tarball. Erin, could you please provide your thoughts?

comment:6 Changed 8 years ago by erinn

I think it's probably easier for everyone if you have your own git repo for rpm-related files, because otherwise you will have to submit patches to tor.git every single time you make a change, or run the risk of your local changes being out of sync with what's in tor.git. I guess it depends on how many changes you think you'll be making, but in theory what's in git should be what's in the rpm, and while Nick is generally very quick to merge, it could get annoying for you to ask for it all the time. Keep in mind that the ideal way for you to submit patches is to have a branch that can be merged from, and you will have to add a changes file each time. IMO there is a lot less overhead to just keeping it all in your own repo.

comment:7 in reply to:  5 Changed 8 years ago by rransom

Replying to marlowe:

Let me consult with erinn, but I don't think we will need a separate git repo. The rpm shouldn't include any files which wouldn't be included in the source tarball. Erin, could you please provide your thoughts?

Someday you will make a packaging mistake and need to fix it without waiting for the next release of Tor.

Also, we want each package's source tree to correspond to a Git tag in the repo which contains the packaging files (at a minimum, the .spec file).

Both of those issues are much easier to deal with if the packaging files are in a separate repo. (That's how the Debian package is maintained, too.)

comment:8 Changed 8 years ago by arma

i agree with erinn and rransom

comment:9 Changed 8 years ago by Sebastian

If Marlowe confirms, we'll need these things: A patch to rip out the rpm stuff from tor.git and the resulting tarball, an ldap account for marlowe, and a new repository name and description so we can add it to our git repositories.

comment:10 Changed 8 years ago by marlowe

I confirm. Just let me know to whom I need to talk to get the above items completed.

comment:11 in reply to:  9 ; Changed 8 years ago by arma

Replying to Sebastian:

A patch to rip out the rpm stuff from tor.git and the resulting tarball

Several of us can do this part. The plan is to rip it out of 0.2.3, yes?

an ldap account for marlowe

Done (finally): #5260

and a new repository name and description so we can add it to our git repositories.

Shall we call it rpm/tor.git to go with debian/tor.git? That way there can be an rpm/obfsproxy.git someday too.

comment:12 in reply to:  11 ; Changed 8 years ago by Sebastian

Replying to arma:

Replying to Sebastian:

A patch to rip out the rpm stuff from tor.git and the resulting tarball

Several of us can do this part. The plan is to rip it out of 0.2.3, yes?

I was thinking 0.2.2, since we'll have rpms for 0.2.2.

and a new repository name and description so we can add it to our git repositories.

Shall we call it rpm/tor.git to go with debian/tor.git? That way there can be an rpm/obfsproxy.git someday too.

Yes, that was my suggestion as well. Marlowe liked it I believe

comment:13 Changed 8 years ago by erinn

Should we give marlowe access to our existing rpm build vms? If so we probably need new ones for fedora whatever-the-latest-version is and probably OpenSUSE as well. If not, it's still good to know so we can get rid of them and make new vms for other things.

comment:14 Changed 8 years ago by Sebastian

Cc: sebastian removed
Component: Tor bundles/installationRPM packaging
Owner: changed from erinn to marlowe

comment:15 in reply to:  12 ; Changed 8 years ago by marlowe

Replying to Sebastian:

Replying to arma:

Replying to Sebastian:

A patch to rip out the rpm stuff from tor.git and the resulting tarball

Several of us can do this part. The plan is to rip it out of 0.2.3, yes?

I was thinking 0.2.2, since we'll have rpms for 0.2.2.

Rather than ripping out individual pieces from tor git, might it make more sense for me to pull the pieces I need and directly import them. It could save everyone else some time.

and a new repository name and description so we can add it to our git repositories.

Shall we call it rpm/tor.git to go with debian/tor.git? That way there can be an rpm/obfsproxy.git someday too.

Yes, that was my suggestion as well. Marlowe liked it I believe

rpm/tor.git works beautifully. I like the expandability of it.

comment:16 in reply to:  13 Changed 8 years ago by marlowe

Replying to erinn:

Should we give marlowe access to our existing rpm build vms? If so we probably need new ones for fedora whatever-the-latest-version is and probably OpenSUSE as well. If not, it's still good to know so we can get rid of them and make new vms for other things.

I would prefer access to the current build environment if possible. If that is not a possibility, could I get the VM images and I will run them at home if possible.

comment:17 in reply to:  15 Changed 8 years ago by arma

Replying to marlowe:

Rather than ripping out individual pieces from tor git, might it make more sense for me to pull the pieces I need and directly import them. It could save everyone else some time.

I believe the way weasel did it for Debian was to clone the Tor repo while it still had the debian stuff in it, have us remove the debian stuff from the Tor repo, merge that commit with a --don't-take-the-changes git option, and now he has his own Tor tree with a debian/ directory. He does a merge whenever we do a git tag, and can build his rpm from what looks to the build process like a Tor git.

comment:18 in reply to:  13 Changed 8 years ago by arma

Replying to erinn:

Should we give marlowe access to our existing rpm build vms? If so we probably need new ones for fedora whatever-the-latest-version is and probably OpenSUSE as well. If not, it's still good to know so we can get rid of them and make new vms for other things.

If you're ok with it, that certainly seems like the simplest approach. I admit I haven't followed where all the VMs live, who has access, how they stay updated, what else having access implies, etc.

comment:19 Changed 8 years ago by marlowe

Okay, taking a look at what we currently do, here are the VMs I think we need to maintain:

CentOS 5
CentOS 6
OpenSuSE 12.1
OpenSuSE 11.4
Fedora 15
Fedora 16

CentOS 4 is EOL and can be taken offline. We might want to add Fedora 17 as well when it is released.

comment:20 Changed 3 years ago by cypherpunks

Cc: erinn, mikeperry, phobos, arma, marlowe@antagonism.org, erinn, mikeperry, phobos, arma, marlowe@antagonism.org
Resolution: invalid
Severity: Normal
Status: newclosed

The torproject does not longer provide RPMs.

Note: See TracTickets for help on using tickets.