Opened 7 years ago

Closed 7 years ago

#6749 closed task (fixed)

Git repo account for hiviah - rpm building

Reported by: hiviah Owned by:
Priority: Medium Milestone:
Component: Internal Services/Tor Sysadmin Team Version:
Severity: Keywords:
Cc: nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The repo is supposed to be for two kinds of code:

  1. build scripts and docs that are specific for official rpm builds on the tpo VMs (though not that useful for end-user or downstream)
  2. branches for fixes to tor.spec and startup scripts to be merged later

Child Tickets

Attachments (1)

0001-Removed-dependency-on-tor.spec.-Removed-tor.spec.in.patch (14.4 KB) - added by hiviah 7 years ago.
Patch to remove tor.spec.in from main repo

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 years ago by nickm

Is this something that should be done with rpm/tor.git for the official parts? If so the right course of action is to get hiviah an ldap account.

comment:2 Changed 7 years ago by nickm

Ah; I just heard that hiviah _does_ have an ldap account. Cool.

Hiviah, would it work if you got write permissions on rpm/tor.git, and a new hiviah/tor-rpm.git for staging ?

Marlowe has write permissions on rpm/tor.git right now. Marlowe, any objections here?

comment:3 Changed 7 years ago by nickm

(To be clear, in case some other gitolite admin gets to this first after hiviah and marlowe respond, and assuming that the above arrangement is what hiviah had in mind, and assuming that marlowe doesn't say "omg no", I am okay with the above.)

comment:4 Changed 7 years ago by Sebastian

marlowe is fine with it (stated so on irc). In any case, it seems wise to start out with the staging repository and only push to the official one after the staging repo looks good, I think. I'm making a user repository for him now, and we can change the access for the official repository after everyone has had a chance to pitch in.

comment:5 Changed 7 years ago by marlowe

No problems on my end as noted by Sebastian.

comment:6 in reply to:  2 Changed 7 years ago by hiviah

Replying to nickm:

Hiviah, would it work if you got write permissions on rpm/tor.git, and a new hiviah/tor-rpm.git for staging ?

That would work. I'd do it similarly as the debian packaging goes:

21:28 < marlowe> which brings up the issue of if there is a change in the spec 
    file without a planned release of tor
21:28 < Sebastian> that was what I initially suggested as probably good enough, 
    but it has some drawbacks, for example, you cannot write a spec file for a 
    certain tagged version of Tor  after it has already been tagged.
21:28 < marlowe> means an out of band release
21:29 < marlowe> I think the debian model might work.
21:29 < marlowe> it would just mean moving the spec file down a directory and 
    adjusting accordingly
21:29 < Sebastian> The way weasel does it for Debian is that he merges the new 
    release into his repository, makes the necessary changes (at lest updating 
    the changelog, sometimes patches too), then tags his own release

The hiviah/tor-rpm.git would track the build scripts and docs used on feddei.

comment:7 Changed 7 years ago by Sebastian

can we chat about this on irc at some point? Then we could go ahead here. Thanks

comment:8 in reply to:  7 Changed 7 years ago by hiviah

Replying to Sebastian:

can we chat about this on irc at some point? Then we could go ahead here. Thanks

I'll be available on tomorrow, Friday Sep 6 7PM CEST (5PM UTC). Probably also sooner during the day (I'll try to check since noon CEST).

Sorry I missed your message on irc.

comment:9 Changed 7 years ago by Sebastian

Nick, how does the plan sound to provide a patch for 0.2.3 which removes the tor.spec.in file from tor.git, and then use that as a baseline for the rpm.git repo with that patch reverted? I suspect you'll not be thrilled to do this in 0.2.2 (the tor.spec file is part of the tarball unfortunately)

comment:10 Changed 7 years ago by nickm

I'd prefer to do as little as possible to 0.2.3. Is it possible to remove tor.spec from tor proper in 0.2.4 instead?

comment:11 Changed 7 years ago by hiviah

I'm fine with changing it in 0.2.4.x.

I've tested removing tor.spec(.in) from Makefile.am and configure.in for 0.2.2.38 and 0.2.3.21-rc, the default and 'dist-gzip' make targets seem to build fine.

comment:12 Changed 7 years ago by hiviah

Attaching patch to remove tor.spec.in and dependency on it for 0.2.4.x. Build and packaging source distribution tarball seem to work fine with the patch applied.

Changed 7 years ago by hiviah

Patch to remove tor.spec.in from main repo

comment:13 Changed 7 years ago by nickm

Thanks; applied!

(Small note: please turn on whatever feature in your editor is used to highlight whitespace at the end of lines.)

comment:14 Changed 7 years ago by hiviah

Sebastian: the rpm repo is pushed into https://gitweb.torproject.org/user/hiviah/rpm-tor.git. As we discussed, master tracks current master (0.2.4.x) and rpm-release-0.2.3 tracks release-0.2.3 of origin.

Maybe I should sign the rpm-tor-xxx tags I make, too?

comment:15 Changed 7 years ago by weasel

Resolution: fixed
Status: newclosed

hiviah has an ldap account for a while now. If anything else still needs doing that's a different ticket.

Note: See TracTickets for help on using tickets.