Developer Stuff
This page is intended as information for developers and contributors.
For Contributors
Making a patch
The process of making a patch is fairly simple:
- If you don't know what you want to patch, figure it out. It's pointless to muck about with getting non-release code if you're not sure what you want to change yet ;)
- Check out the Monotone code for what you want to change following the instructions in the Developer Monotone Access section below.
- Make the code changes you want.
- Try to match the style of the code you're modifying as best you can.
- If you need to modify configure.ac, Makefile.am, or other autotools-related files, do so cautiously.
- TEST EVERYTHING before proceeding.
- You may commit to your local database if you wish, but you will not be able to push.
- Make the patch: mtn diff > ~/something.patch (of course, substituting a real name in place of "something"). You may need to look at your database via monotone-viz or mtn log and specify revisions to diff between, depending on how you made your changes.
- Submit the patch here for Guifications 2.x or here for the Plugin Pack, or by sending to one of our Mailing Lists
For Project Developers
Developer Monotone Access
We have moved to using Monotone for our version control. Read Using Pidgin Monotone for an overview of monotone and links to documentation. If, and only if, you are a Guifications or Plugins project developer, generate a monotone key in the form of yournick@….
We recommend keeping our plugins in a separate database from Pidgin. To do this, you will need to create a new database.
~$ mtn -d /path/to/new/database db init
Now pull our history.
~$ mtn -d /path/to/new/database pull guifications.org BRANCH
You will need to substitute BRANCH with a real branch name. Our branch names are:
- org.guifications.gf2 - Guifications 2.x
- org.guifications.plugins - the Plugin Pack
- org.guifications.autoprofile - the Autoprofile plugin
Note that you cannot simply use a wildcard pattern, such as org.guifications.* to pull from us. This is because we use multiple monotone databases on our server.
Next you will need to check out a working copy.
~$ mtn -d /path/to/new/db co -b BRANCH WORKINGDIR
Again, BRANCH must be replaced with the correct branch name. WORKINGDIR is optional and represents the name you would like your working copy's directory to have.
To commit, once you have a working copy, use mtn -k yournick@guifications.org commit. You may need to mtn -k yournick@guifications.org push the first time you try to push revisions to the server.
Release Process
To make releases for the Purple Plugins project, there are a few things that need to be done. It's long, so be patient :)
Build the distribution tarballs
- Download the released Pidgin tarball and install. (Packages can be used as well, but likely none of the distros will have the newest release packaged when we need to release.) Alternatively, check out the tag for the new Pidgin release from their version control.
- If you haven't already, check out a copy of the databases' HEAD. Make sure you've pulled, updated, and merged if necessary!
- Edit configure.ac, ChangeLog, and (if you keep separate commit and compile trees) VERSION in both Guifications 2.x and the Plugin Pack so that they reflect the new releases' versions.
- Run autogen.sh for Guifications 2.x.
- Run make -s to build and hide all the make messages--this will help find errors/warnings from the compiler more quickly. Fix any errors you find.
- If make -s gave no errors that need fixing, run make dist and look for errors. If there are any errors here, fix them, committing changes as you go.
- Once make dist completes successfully, sign the tarballs.
gpg -ba pidgin-guifications-version.tar.bz2 gpg -ba pidgin-guifications-version.tar.gz
- Upload the tarballs and .asc signatures to your home directory on guifications.org: scp pidgin-guifications-version.tar.* guifications.org:
- Run autogen.sh --with-plugins=all in the Plugin Pack.
- Run make -s to build and hide all the make messages--this will help find errors/warnings from the compiler more quickly. Fix any errors you find.
- Build any abusive plugins to make sure they build with no problems. Again, fix any errors.
- If make -s gave no errors that need fixing, run make dist and look for errors. If there are any errors here, fix them, committing changes as you go.
- Once make dist completes successfully, sign the tarballs.
gpg -ba purple-plugin_pack-version.tar.bz2 gpg -ba purple-plugin_pack-version.tar.gz
- Upload the tarballs and .asc signatures to your home directory on guifications.org: scp purple-plugin_pack-version.tar.* guifications.org:
Tag the releases in Monotone
FIXME!!!!!
Release the distribution tarballs
- Get a shell on guifications.org: ssh guifications.org
- Replace the Guifications 2.x release with the new one:
cd /var/www/guifications.org/downloads/Guifications2 mv * ../Guifications2\ Archive mv ~/pidgin-guifications-* . chgrp plugins * chown 644 *
- Replace the Plugin Pack release with the new one:
cd ../Plugin\ Pack mv * ../Plugin\ Pack\ Archive mv ~/purple-plugin_pack-* . chgrp plugins * chown 644 *
News Item
- Log into http://plugins.guifications.org/trac/
- Go to the Admin interface and select News from the Admin menu.
- Create a new news item. Make sure to point to the Downloads section.
Final cleanup
- Run mtn status from the directories you ran make dist in to see if any translations changed as a result of the updates make dist performs. If translations have changed, commit them (mtn commit and use something similar to "make dist'ed po files" for the commit message).
- Edit the configure.ac, ChangeLog, and VERSION files you edited earlier, and change their versions to the next version number, with svn appended. For example, if the release of Guifications 2.x you just made is numbered 2.14, then change the version to 2.15svn in these three files. Do this for both Guifications 2.x and the Plugin Pack. Commit these changes.
Windows Packages
If you have access to a windows machine, preferably running Windows 2000 or a later NT-based Windows platform, then you can build the Windows packages. The process is a bit painful, but here goes. (Note: many of these steps are unnecessary if you don't wish to build the installer or zip files, or if you are not planning on building both guifications and the plugin-pack)
- Set up a Windows Pidgin Build Environment
- Build Pidgin: make -s -f Makefile.mingw
- mkdir win32-install-dir/plugins
- Download the released Guifications and Plugin Pack .tar.bz2 packages to your cygwin home directory.
- cd pidgin/plugins
- tar jxvf ~/pidgin-guifications-version.tar.bz2
- cd pidgin-guifications-version && make -s -f Makefile.mingw all install installer
- Using Windows Explorer, go to your cygwin home directory, then into pidgin-version\win32-install-dir. Make a zip archive containing the three directories you see here.
- Move the zip file somewhere convenient, say C:\.
- In the cygwin command prompt, mv pidgin-guifications-version.exe /cygdrive/c (or modify as appropriate to match where you placed the zip file).
- rm -r ~/pidgin-version/win32-install-dir/* && mkdir ~/pidgin-version/win32-install-dir/plugins
- Go back to ~/pidgin-version/pidgin/plugins/ in your cygwin window.
- tar jxvf ~/purple-plugin_pack-version.tar.bz2
- Here's where you will likely run into problems. Fix any you can as best you can. If you can't fix them, find someone who can. cd purple-plugin_pack-version && make -s -f Makefile.mingw all install
- If you made it through the last step, use Windows Explorer and go to the win32-install-dir again. Make a zip archive containing everything in the plugins directory there. Place this zip file with the other files you built.
- In your cygwin window, go to the directory in which you placed all your Windows packages. Then scp each package to your home directory on guifications.org and follow the instructions above to move them to the correct directories and assign the correct group and permissions.
