(Py)Obfsproxy Debian packages
Greetings (Debian) people, we have decided to keep the Obfsproxy name and simply replace the old C codebase with the new Python codebase. It seems that 'obfsproxy' is an extremely powerful brand name and changing it will result in user confusion. That said, what is the best way to update the Debian packages so that they contain the Python codebase? I remember weasel telling me that updated packages can only be included in Debian after wheezy is stabilized. Can we have Python Obfsproxy packages in deb.torproject.org in the meantime? Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'. (Sorry for the duplicate mail, but I forgot to CC tor-dev in the previous one.)
George Kadianakis:
we have decided to keep the Obfsproxy name and simply replace the old C codebase with the new Python codebase. It seems that 'obfsproxy' is an extremely powerful brand name and changing it will result in user confusion.
That said, what is the best way to update the Debian packages so that they contain the Python codebase?
obfsproxy will be in Wheezy. So in any cases, if the binary package name is going to stay the same, it would probably be better to have a version number for the Python codebase higher than the previous implementation.
Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'.
The package is waiting in the NEW queue: http://ftp-master.debian.org/new/pyobfsproxy_0.0.2-1.html Do you plan to rename the Git repository, project page and all for the Python codebase? If not, we can have the source package "pyobfsproxy" create a "obfsproxy" binary package that would superseed the package currently in Debian. It could only be done after the actual "obfsproxy" is removed, though. Should I ask the ftpmasters to remove pyobfsproxy from the NEW queue until we sort this out? -- Jérémy Bobbio .''`. lunar@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
On Fri, 22 Mar 2013, Jérémy Bobbio wrote:
George Kadianakis:
That said, what is the best way to update the Debian packages so that they contain the Python codebase?
obfsproxy will be in Wheezy. So in any cases, if the binary package name is going to stay the same, it would probably be better to have a version number for the Python codebase higher than the previous implementation.
Or we just use an epoch. That's what they are for.
Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'.
The package is waiting in the NEW queue: http://ftp-master.debian.org/new/pyobfsproxy_0.0.2-1.html
Do you plan to rename the Git repository, project page and all for the Python codebase? If not, we can have the source package "pyobfsproxy" create a "obfsproxy" binary package that would superseed the package currently in Debian. It could only be done after the actual "obfsproxy" is removed, though.
Should I ask the ftpmasters to remove pyobfsproxy from the NEW queue until we sort this out?
Probably. If we want to re-use the source package name obfsproxy that's fine with me too. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
George Kadianakis:
we have decided to keep the Obfsproxy name and simply replace the old C codebase with the new Python codebase. It seems that 'obfsproxy' is an extremely powerful brand name and changing it will result in user confusion.
That said, what is the best way to update the Debian packages so that they contain the Python codebase?
obfsproxy will be in Wheezy. So in any cases, if the binary package name is going to stay the same, it would probably be better to have a version number for the Python codebase higher than the previous implementation.
Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'.
The package is waiting in the NEW queue: http://ftp-master.debian.org/new/pyobfsproxy_0.0.2-1.html
Do you plan to rename the Git repository, project page and all for the Python codebase? If not, we can have the source package "pyobfsproxy" create a "obfsproxy" binary package that would superseed the package currently in Debian. It could only be done after the actual "obfsproxy" is removed, though.
As far as Git repositories are concerned, weasel suggested moving /obfsproxy.git to /pluggable-transports/obfsproxy-legacy.git and moving /pluggable-transports/pyobfsproxy.git to /pluggable-transports/obfsproxy.git . I think I like this plan. I should also change the Python obfsproxy codebase to remove all the 'pyobfproxy' artifacts, and to have a setupscript that creates an 'obfsproxy' binary.
Should I ask the ftpmasters to remove pyobfsproxy from the NEW queue until we sort this out?
I think this is a good idea. Sorry for the extra trouble.
-- Jérémy Bobbio .''`. lunar@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
George Kadianakis:
we have decided to keep the Obfsproxy name and simply replace the old C codebase with the new Python codebase. It seems that 'obfsproxy' is an extremely powerful brand name and changing it will result in user confusion.
That said, what is the best way to update the Debian packages so that they contain the Python codebase?
obfsproxy will be in Wheezy. So in any cases, if the binary package name is going to stay the same, it would probably be better to have a version number for the Python codebase higher than the previous implementation.
Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'.
The package is waiting in the NEW queue: http://ftp-master.debian.org/new/pyobfsproxy_0.0.2-1.html
Do you plan to rename the Git repository, project page and all for the Python codebase? If not, we can have the source package "pyobfsproxy" create a "obfsproxy" binary package that would superseed the package currently in Debian. It could only be done after the actual "obfsproxy" is removed, though.
So here is my list of things that must be done to complete this transition: """ Codebase changes: - Change the format of future tags _and_ release tarballs from "pyobfsproxy-X.X.X" to "obfsproxy-X.X.X". - Change the name of the executable of Python-obfsproxy from "pyobfsproxy" to "obfsproxy". - I don't plan to replace all "pyobfsproxy" strings to "obfsproxy" in the codebase. I will change the ones that are easy to replace, but I will leave others intact. I will also leave the old tags (pyobfsproxy-0.0.1, etc.) as is. - Tag a new Python-obfsproxy release: "obfsproxy-0.2.1". The last C-obfsproxy release was "obfsproxy-0.1.4", so the new tag should give the impression that Python-obfsproxy is more advanced. Git repository changes: - Move /obfsproxy.git to /pluggable-transports/obfsproxy-legacy.git . - Move /pluggable-transports/pyobfsproxy.git to /pluggable-transports/obfsproxy.git Linux distro packages changes: - Notify Linux distro package maintainers that the codebase of their "obfsproxy" package should be replaced with the newer Python codebase. - Somehow (blog post?) notify bridge operators that they should start using the new obfsproxy, with all the new transports enabled. Miscellaneous: - Try to fix Internet hyperlinks that point to gitweb.tpo/obfsproxy.git or other dead links caused by the operation above. - Try to edit documents on the net that use the term "Pyobfsproxy" in a confusing way. """ I'd like the "Codebase changes" section to be completed before we switch git repositories or before we build Linux packages. Can you please ACK that the "Codebase changes" section makes sense to you, or comment on how it could be improved? If I get an ACK, I will move forward with the codebase changes and then start speaking to people about the git repo switch and the Linux packages. (I have a small patch that implements most of the codebase changes (everything except the release tagging) here: https://gitweb.torproject.org/user/asn/pyobfsproxy.git/commitdiff/97da554965... ) (CCed some more package maintainers of Obfsproxy)
Another issue that Lunar raised in IRC is whether bridge operators will have to change their torrc after they upgrade to the new obfsproxy package. The answer (unfortunately) is yes; the obfsproxy torrc line will have to change in two ways after an upgrade: a) Bridge operators will have to change their ServerTransportPlugin line to include new transports. So for example, after the upcoming upgrade, they will have to change: "ServerTransportPlugin obfs2 /usr/local/bin/obfsproxy --managed" to "ServerTransportPlugin obfs2,obfs3 /usr/local/bin/obfsproxy managed" . This will be necessary till ticket #3725 is implemented, or till we have better obfuscated bridge bundles, or till Linux distro packages can somehow change tor's configuration. b) In the current typical "ServerTransportPlugin obfs2 /usr/local/bin/obfsproxy --managed" line, "--managed" will have to be replaced with "managed" after the upgrade. This has to do with the way Python obfsproxy does command-line-argument parsing, and how argparse subparses are still a bit sucky: http://bugs.python.org/issue9253 . I haven't found a nice solution for this, except from not using subparses but this will require a big codebase change. BTW, this will only happen the first time a user upgrades from C-Obfsproxy to Python-obfsproxy. Since the manual torrc update is not so easy to avoid, my suggestion is to add a post-install hook to the obfsproxy packages that say "Hey, thanks for upgrading obfsproxy. Don't forget to change your torrc line to X". What do you think? ( Lunar suggested dodging b) by scanning the sys.argv for "--managed" and inplace replace it with "managed" before the CLI parsing happens. This is extremely evil, but it's not too hard to implement and might even work. If we decide that Python-obfsproxy MUST recognize "--managed", I might consider this. )
"George Kadianakis" <desnacked@riseup.net> writes:
George Kadianakis:
we have decided to keep the Obfsproxy name and simply replace the old C codebase with the new Python codebase. It seems that 'obfsproxy' is an extremely powerful brand name and changing it will result in user confusion.
That said, what is the best way to update the Debian packages so that they contain the Python codebase?
obfsproxy will be in Wheezy. So in any cases, if the binary package name is going to stay the same, it would probably be better to have a version number for the Python codebase higher than the previous implementation.
Lunar, how did the Debian package creation go? Do you need any help? We should name the new packages 'obfsproxy'.
The package is waiting in the NEW queue: http://ftp-master.debian.org/new/pyobfsproxy_0.0.2-1.html
Do you plan to rename the Git repository, project page and all for the Python codebase? If not, we can have the source package "pyobfsproxy" create a "obfsproxy" binary package that would superseed the package currently in Debian. It could only be done after the actual "obfsproxy" is removed, though.
So here is my list of things that must be done to complete this transition:
""" Codebase changes:
- Change the format of future tags _and_ release tarballs from "pyobfsproxy-X.X.X" to "obfsproxy-X.X.X".
- Change the name of the executable of Python-obfsproxy from "pyobfsproxy" to "obfsproxy".
- I don't plan to replace all "pyobfsproxy" strings to "obfsproxy" in the codebase. I will change the ones that are easy to replace, but I will leave others intact. I will also leave the old tags (pyobfsproxy-0.0.1, etc.) as is.
- Tag a new Python-obfsproxy release: "obfsproxy-0.2.1". The last C-obfsproxy release was "obfsproxy-0.1.4", so the new tag should give the impression that Python-obfsproxy is more advanced.
Git repository changes:
- Move /obfsproxy.git to /pluggable-transports/obfsproxy-legacy.git .
- Move /pluggable-transports/pyobfsproxy.git to /pluggable-transports/obfsproxy.git
Linux distro packages changes:
- Notify Linux distro package maintainers that the codebase of their "obfsproxy" package should be replaced with the newer Python codebase.
- Somehow (blog post?) notify bridge operators that they should start using the new obfsproxy, with all the new transports enabled.
Miscellaneous:
- Try to fix Internet hyperlinks that point to gitweb.tpo/obfsproxy.git or other dead links caused by the operation above.
- Try to edit documents on the net that use the term "Pyobfsproxy" in a confusing way. """
Now that the obfsproxy-0.2.1 is done [0], maybe we should do the git repo pivot. weasel, would you do the honors? I guess what must be done is: - Move /obfsproxy.git to /pluggable-transports/obfsproxy-legacy.git . - Move /pluggable-transports/pyobfsproxy.git to /pluggable-transports/obfsproxy.git . - Add redirects or HTTP 301s to /obfsproxy.git and to /pluggable-transports/pyobfsproxy.git . Thanks! [0]: https://gitweb.torproject.org/pluggable-transports/pyobfsproxy.git/tag/2ba59...
On Tue, 09 Apr 2013, George Kadianakis wrote:
weasel, would you do the honors?
I guess what must be done is: - Move /obfsproxy.git to /pluggable-transports/obfsproxy-legacy.git . - Move /pluggable-transports/pyobfsproxy.git to /pluggable-transports/obfsproxy.git . - Add redirects or HTTP 301s to /obfsproxy.git and to /pluggable-transports/pyobfsproxy.git .
Done the first two as discussed on IRC. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
participants (3)
-
George Kadianakis -
Jérémy Bobbio -
Peter Palfrader