The iPKG upload
mechanism enables any authorized package maintainer to
upload packages directly to feeds on handhelds.org.
Becoming a Handhelds.org Package Maintainer
Email the openpgp public key that you will use to sign the
packages that you wish to upload to Jamey Hicks
(jamey@handhelds.org).
To create a PGP public/private key pair suitable for use in
signing packages, use the gnupg package (or
equivalent) and execute the following command:
bash$ gpg --gen-key
Here is how I configured the keypair I am using;
- Choose the default keysize of 1024 bits.
- Key does not expire.
- Specify your name, email address and comment to identify
the key.
- Give it a passphrase to prevent someone else from
misusing your key.
See the gnupg section on Generating a new
keypair for a more detailed description of this step.
Here is a Jamey's public key, uploaded to
the wwwkeys.pgp.net key server.
Submitting keys
Email the public key you will be using to sign packages to
jamey@handhelds.org. The following commands will work. First list your
keys with list-keys, then select one for export to send to me.
bash$ gpg --list-keys
/udir/jamey/.gnupg/pubring.gpg
------------------------------
pub 1024D/423D317E 2001-12-06 Jamey Hicks
uid Jamey Hicks
sub 1024g/E262D1E8 2001-12-06
Now select the pub key ID of the key you will use to sign packages, and
pass that to gpg export to say which key to export and also put it into
the subject of the message to jamey@handhelds.org for sanity checking.
bash$ gpg --armor --export 423D317E | mail -s '[KEY] 423D317E' jamey@handhelds.org
Building iPKGS
See ipkg wiki pages
Signing iPKGS
Before an ipkg can be uploaded, it must be signed as follows:
gpg -sb --armor foo.ipk
This signs foo.ipk with your public key, putting the
signature in the ASCII file foo.ipk.asc.
Uploading iPKGS
Once you have a signed package, you can upload it to the
unstable feed using http://www.handhelds.org/cgi-bin/upload-package.cgi.
Uploading Sources
Familiar has been Debian-derived, and so we are requesting sources be
uploaded as Debian source packages.
A Debian source package for package foo consists of three files:
- foo-1.2.dsc
- Description of the foo package
- foo-1.2.orig.tar.gz
- Original sources of version 1.2 the foo software package.
- foo-1.2-fam1.diff.gz
- Compressed patch to Familiarize version 1.2 of the foo software pacakge.
If the original source is unchanged for Familiar, then there will be no
.diff.gz. Also, multiple patch files can be concatenated, so not every
version of the sources needs to have an accompanying .orig.tar.gz.
Bugzilla
Periodically, one of the handhelds.org administrators runs
tools/packman/update-bugzilla.py to update the
product/component/defaultowner info in the
Handhelds.org
Bugzilla database.
Translating Web Content
If you are interested in translating content on handhelds.org into a
non-English language, please send email to admin@handhelds.org to get the
necessary CVS access. The procedure for translating a web page is as
follows:
Check out the relevant portions of the web site from the CVS repository
at :cvs.handhelds.org:/cvs. The main pages are in
/cvs/website, and virtual.handhelds.org pages are in
/cvs/virtual (for example, familiar.handhelds.org pages are in
/cvs/familiar).
If nobody else has already done so, create and commit the left-hand
navigation bar include file for your language as
/cvs/website/include/navleft.inc.lang, where
lang is an Internet standard language tag as defined in RFC 1766. For
example, the French version of that file is
/cvs/website/include/navleft.inc.fr.
Choose a page to translate. The translation status page displays a list of
untranslated and out-of-date pages.
If nobody else has already done so, add the necessary PHP header and
footer to the English version of the page that you're translating. The
English pages have no .lang filename extension. Pages on the
main site should begin with this:
<?
require 'hh.inc';
hh_opt('rcsid', $Id$');
hh_header('Put Page Title Here');
?>
and end with this:
<?hh_footer()?>
Pages on virtual handhelds.org sites should begin with this:
<?require 'hhlang.inc'?>
Create and commit the page that you're translating as
file.lang, where file is the filename of the English page
and lang is the appropriate Internet standard language tag. For
example, the French version of the main index.html page is
/cvs/website/index.html.fr.
We don't yet have a mechanism for autoselecting Wiki page
translations.
Implementation
The server-side language selection mechanism is implemented in PHP code
included by each translated page. The PHP code does the following:
Parse the client-provided Accept-Language HTTP header into a list of
language tags, sorted by client preference.
For each tag in that list, check for the existence of a translated page
whose name is that of the requested page plus "." plus the tag. If
such a page is found, return it in place of the remainder of the page being
processed.
If no translated page is found, return the requested page.
Main site only: perform a similar check for and replacement of the
left-side navigation bar.
Reasons for handling translations in PHP instead of using Apache's built-in
mechanism:
Apache's built-in mechanism requires that every translated page have no
extensionless variant, so e.g. index.html would need to be renamed to
index.html.en or index.html.html. Renaming files throughout the website in
that manner might cause some disruption.
Some human-readable words are stored as PHP arrays, for example the
navigation bar on the left side of every www.handhelds.org page. I've been
unable to find a way for PHP to get Apache to apply its language-choice magic
to such arrays.
(It doesn't work to do e.g. require
'http://handhelds.org/include/navleft.inc', because PHP doesn't seem to
propagate the Accept-Language HTTP header to the Apache subrequest.)
|
