Juan Alcaine is interested in helping with the arm rpms and the first step for this is to start uploading the arm and torctl rpms to the deb.tpo rpm repository (see the "Arm RPM Package" tor-assistants@ thread for more context).
I'd appreciate upload access and help for how to do this. Both arm and torctl are pure python packages so hopefully we'll be able to upload a single rpm to all distros with minimal hassle.
Erinn mentioned on irc that we might need to put this on hold for a month but hopefully we'll be able to make some progress before then (it would be sad if Juan disappeared because we delayed a long time on this).
Cheers! -Damian
PS. Picking this component since we don't have one for packaging/repos in general.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
Do you want upload access or do you want to get Juan upload access? I think it is actually more important to get the rpms into Fedora than our repos.
As for upload access, I don't have any control over that. Adding weasel to cc.
For actually uploading the rpms, right now it is kind of complicated (or a mess) because I use one of my keys to sign the rpms and also the repos they are in (each rpm dir serves as its own rpm repository). Someone would need to figure out how to generalize that so that more people can sign the repos in the normal rpm-distro way, and I have too many very high priority things on my plate right now; there is no way I will have time to look at this between now and, let's say, Nov 3. But I may be able to automate some of it by then, since that is one of my "very high priority" things, which could make it easier.
So, to summarize this already long-winded comment:
get the rpms into Fedora first. that's where most of the users are. I don't have stats, but I don't think our rpm repos have many users.
ask weasel about upload access
find a way for me to generalize the rpm repos such that multiple uploaders can do it (giving me a document or explaining how other distros do it here is fine)
Do you want upload access or do you want to get Juan upload access?
Me. I'd be signing and uploading the arm/torctl rpms. Juan would then test and maybe upload them to Fedora.
I think it is actually more important to get the rpms into Fedora than our repos.
I strongly disagree unless the Fedora repos are already getting an up to date copy of Tor. As mentioned in the tor-assistants@ thread there's no point for arm or torctl to be present in any repositories where Tor doesn't reside.
But I may be able to automate some of it by then, since that is one of my "very high priority" things, which could make it easier.
That would be sweet - fingers crossed that it works.
get the rpms into Fedora first. that's where most of the users are. I don't have stats, but I don't think our rpm repos have many users.
Hm... we tell users to avoid native rpm repositories since from what we understand they're unmaintained and dangerous. I agree that it's preferable for Tor/arm/torctl to all reside there with a maintainer since most users probably ignore this warning, but until we have this maintainer it seems odd to say "Yay, arm/torctl are in native repositories! But don't use them for tor - that's dangerous."
find a way for me to generalize the rpm repos such that multiple uploaders can do it (giving me a document or explaining how other distros do it here is fine)
Hello, I've been working in the RPMs the last days improving the compatibility with other distros. Now it compiles ok in Fedora, OpenSuse and CentOS 6.
I have done some research and I think we cannot do a single package that fits all distros, correct me if I'm wrong.
I have run tests against CentOS, Suse and Fedora and I have found these problems:
Different path in Suse documentation files.
Different dependencies because the package names are not the same across distros.
RPM in CentOS 5 uses MD5 as hash algorithm, and don't support the SHA of newer distros.
CentOS 5 ships python 2.4.3, but >= 2.5.0 is needed.
We can generate distro-specific RPMs from the same spec file if we have the right build environment. I have updated my repo with all the changes, and I include the RPMs generated in my Fedora system.
As it seems it will be a while until the packages reach the Tor repos, I'm going to submit these packages to Fedora for revision (a long process, too).
Thanks Juan. I added a '--docPath' argument to setup.py for gentoo which should do the trick for suse too. Let me know if there's any upstream changes that can help. -Damian
Let's get these moved into deb.tpo. In regards to the CentOS python issue, CentOS 6 has an appropriate version of Python. Rather than attempt to push a different version of Python on CentOS 5 users, I say we leave well enough alone.
Juan, please drop me an email at marlowe@torproject.org. I may have a line on a sponsor for your package.
Juan - Can you provide a list of the offending packages which are causing the cross distro issues? If necessary, we can create separate spec files as needed.
Good news, I've been sponsored into the Fedora packagers group.
I'm going to do some minor fixes to the package and hope it will be accepted soon, I've been asked about include a .desktop file for running "arm -g", so I'll need a icon file. I picked the image in the header at http://www.atagar.com/arm , do you agree? do you have it in svg or higher quality?
Good news, I've been sponsored into the Fedora packagers group.
Fantastic! On a related note I'll probably be making another arm release in the next couple weeks to get out some bug fixes.
I'll need a icon file. I picked the image in the header at http://www.atagar.com/arm , do you agree? do you have it in svg or higher quality?
Sure. That icon is from an svg in the Oxygen icon set called 'utilities-system-monitor.svg' (though with its border removed). It's used in KDE and iirc dual licensed under GPLv2 and Creative Commons v3 (A, SA).