We need a new RPM maintainer
Hi, all! Ondrej Mikle, who has built our RPMs for a while, is no longer able to do so. (He isn't using RPM distros any more, doesn't have as much free time, and etc.) First: Thanks, Ondrej, for all your hard work! Here's the instructions he sent on how to do it (quoted with permission): {{{ Basically every part of the process is documented here: https://gitweb.torproject.org/user/hiviah/rpm-build-scripts.git/tree/README It's maybe not the best README, because the actual merge-and-build part is in the middle (but I always use it, otherwise I'd just forget all the necessary steps). Nevertheless, the introduction maybe necessary for someone not familiar with the process. The process in the short is: 0. have the environment ready (has to be done just once) 1. clone my own RPM fork which has RPM changes (https://gitweb.torproject.org/user/hiviah/rpm-tor.git) 2. Merge and build according to "MERGING REPO USED FOR RPM BUILDING FROM ORIGIN" 3. Download, review, sign the built RPMs (I used feddei.tpo VM for this, but you can have your own VM as I had last time since feddei.tpo was down) 4. upload to palmeri.tpo 5. distribute to everyone else via "static-update-component deb.torproject.org" on palmeri.tpo I could walk somebody through this, as I said, this is not rocket surgery, mostly attention to detail :) If there ever was a critical need for a special build due to some unforseen bug, I could still do it, but this is for exceptional case only. }}} The easiest way for RPMs to happen would be if somebody who already has a Tor LDAP account wants to step forward and volunteer for a while. It would be harder if this were somebody that we didn't know who volunteered: until our RPM process creates reproducible builds, we need to have some amount of trust in the person who creates them. There may be other issues here too. I am no packaging expert. :) best wishes, -- Nick Mathewson
I can do it. I already package my own RPMs, so I may as well do that properly. No ldap account though. Tom
On 16 Jun 2016, at 15:06, Nick Mathewson <nickm@torproject.org> wrote:
Hi, all!
Ondrej Mikle, who has built our RPMs for a while, is no longer able to do so. (He isn't using RPM distros any more, doesn't have as much free time, and etc.)
First: Thanks, Ondrej, for all your hard work!
Here's the instructions he sent on how to do it (quoted with permission): {{{ Basically every part of the process is documented here:
https://gitweb.torproject.org/user/hiviah/rpm-build-scripts.git/tree/README
It's maybe not the best README, because the actual merge-and-build part is in the middle (but I always use it, otherwise I'd just forget all the necessary steps). Nevertheless, the introduction maybe necessary for someone not familiar with the process.
The process in the short is:
0. have the environment ready (has to be done just once) 1. clone my own RPM fork which has RPM changes (https://gitweb.torproject.org/user/hiviah/rpm-tor.git) 2. Merge and build according to "MERGING REPO USED FOR RPM BUILDING FROM ORIGIN" 3. Download, review, sign the built RPMs (I used feddei.tpo VM for this, but you can have your own VM as I had last time since feddei.tpo was down) 4. upload to palmeri.tpo 5. distribute to everyone else via "static-update-component deb.torproject.org" on palmeri.tpo
I could walk somebody through this, as I said, this is not rocket surgery, mostly attention to detail :)
If there ever was a critical need for a special build due to some unforseen bug, I could still do it, but this is for exceptional case only. }}}
The easiest way for RPMs to happen would be if somebody who already has a Tor LDAP account wants to step forward and volunteer for a while. It would be harder if this were somebody that we didn't know who volunteered: until our RPM process creates reproducible builds, we need to have some amount of trust in the person who creates them.
There may be other issues here too. I am no packaging expert. :)
best wishes, -- Nick Mathewson _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
What is the Tor Project's motivation for providing RPMs (instead of relying on the RPM distro maintainer)? I think jamie is doing a great job at maintaining Fedora's and EPEL RPMs. I switched to his RPMs for their systemd and multi-instance support. The only thing you don't get from Fedora/EPEL is alpha packages.
On Thu, Jun 16, 2016 at 10:06 AM, nusenu <nusenu@openmailbox.org> wrote:
What is the Tor Project's motivation for providing RPMs (instead of relying on the RPM distro maintainer)?
Frankly, I don't know. I don't actually install Tor from packages myself, since I'm nearly always running Tor from master. People who download our RPMs: in what way are they beneficial?
I think jamie is doing a great job at maintaining Fedora's and EPEL RPMs. I switched to his RPMs for their systemd and multi-instance support.
The only thing you don't get from Fedora/EPEL is alpha packages.
On Thu, Jun 16, 2016 at 10:19:15AM -0400, Nick Mathewson wrote:
On Thu, Jun 16, 2016 at 10:06 AM, nusenu <nusenu@openmailbox.org> wrote:
What is the Tor Project's motivation for providing RPMs (instead of relying on the RPM distro maintainer)?
Frankly, I don't know. I don't actually install Tor from packages myself, since I'm nearly always running Tor from master.
People who download our RPMs: in what way are they beneficial?
The last time I had occasion to check (around 6 months ago), the official Tor Project RPMs were actually worse than the Fedora ones: worse integration with Fedora's systemd configuration, no SELinux, and they didn't uninstall cleanly, meaning you had to manually clean up permissions issues in order to switch back to the Fedora packages. Given that maintaining packages is an ongoing effort that requires keeping track of how the distribution is configuring their system, wouldn't it be better to find a way to work with the existing distro maintainers so that, for instance, the current Fedora RPMs could be the officially-endorsed Tor Project RPMs? Cheers, Henry de Valence
On Fri, Jun 17, 2016 at 12:53 PM, Henry de Valence <hdevalence@riseup.net> wrote:
On Thu, Jun 16, 2016 at 10:19:15AM -0400, Nick Mathewson wrote:
On Thu, Jun 16, 2016 at 10:06 AM, nusenu <nusenu@openmailbox.org> wrote:
What is the Tor Project's motivation for providing RPMs (instead of relying on the RPM distro maintainer)?
Frankly, I don't know. I don't actually install Tor from packages myself, since I'm nearly always running Tor from master.
People who download our RPMs: in what way are they beneficial?
Given that maintaining packages is an ongoing effort that requires keeping track of how the distribution is configuring their system, wouldn't it be better to find a way to work with the existing distro maintainers so that, for instance, the current Fedora RPMs could be the officially-endorsed Tor Project RPMs?
Some time ago, there were no distro maintainers for Tor RPM packages, so you had to build them yourself - that's why I started making the packages. The situation has changed and the distro packages AFAIK have these drawbacks: - IIRC there is 2 week wait until package appears (some rule for Fedora packages) - no alpha packages The permission problem is present only if you mix the packages (install from one repo, then from the other), because each one uses different users (affects mostly generated stuff like /var/lib/tor). I'd think that since distro maintainers exist now, it might be better to use their packages. Ondrej
On 06/17/2016 12:53 PM, Henry de Valence wrote:
On Thu, Jun 16, 2016 at 10:19:15AM -0400, Nick Mathewson wrote:
On Thu, Jun 16, 2016 at 10:06 AM, nusenu <nusenu@openmailbox.org> wrote:
What is the Tor Project's motivation for providing RPMs (instead of relying on the RPM distro maintainer)?
Frankly, I don't know. I don't actually install Tor from packages myself, since I'm nearly always running Tor from master.
People who download our RPMs: in what way are they beneficial?
The last time I had occasion to check (around 6 months ago), the official Tor Project RPMs were actually worse than the Fedora ones: worse integration with Fedora's systemd configuration, no SELinux, and they didn't uninstall cleanly, meaning you had to manually clean up permissions issues in order to switch back to the Fedora packages.
The uninstaller deletes what it can, but it can't remove /var/lib/tor entirely, as you'd lose relay keys etc. Anyway, anyone transitioning to the EPEL/Fedora packages needs to do something like this _after_ installing the EPEL/Fedora packages: /bin/chown -R toranon:toranon /var/{lib,log,run}/tor toranon is the username used by those packages. (My postinstall scripts used to check for this, but the EPEL/Fedora's doesn't). Ondrej
Frankly, I don't know. I don't actually install Tor from packages myself, since I'm nearly always running Tor from master.
People who download our RPMs: in what way are they beneficial?
since no one spoke up, I created: https://trac.torproject.org/projects/tor/ticket/19501
participants (6)
-
Henry de Valence -
Nick Mathewson -
Nick Mathewson -
nusenu -
Ondrej Mikle -
Tom van der Woerdt