script to ease its startup as an unprivileged user. While here, split the
Makefile to help the forthcoming mldonkey-gui package.
This makes it very easy to run mldonkey on a dedicated server w/o X11.
Furthermore, this approach is similar to what other systems do (like Gentoo).
Bump PKGREVISION to 3. Ok'ed by wiz@, the maintainer.
the software to work. Run "check_perms -f" to make sure permissions
are correct (it still fixes a setgid problem with "mail/mailman").
Remove mm_cfg.pyc (compiled copy of mm_cfg.py) always, so the package
can be deinstalled cleanly.
Closes PR pkg/24041.
- Added manlifter to the distribution. doclifter no longer strips off file
extensions before appending .xml. Major improvement in parsing of
displays; C function prototypes are now recognized in them.
pkgsrc:
manlifter not installed yet, since it only works when run as "./manlifter"
Enhancements
* Multiple encoding support for trying ID3 title conversion
* GUI refinement tweaks
* New logo and icons
* New command line option to bring BMP to desktop foreground (--activate).
* New compile-time option select XMMS equalization (--with-xmms-eq).
* New translations (Brazilian Portuguese, Breton, Czech, Greek, Hungarian,
Macedonian, Romanian, Slovak)
* Running beep-media-player --version now prints built-in optional components
Bugfixes
* Fixed removal of dead playlist entries
* Fixed dependency information in pkg-config file (bmp.pc)
* Fixed and disambiguated playlist editor accelerators
* Hacked around playlist editor shade bug (now always unshades on launch)
* Many others (see Bugzilla and ChangeLog)
probably have to resurrect the old xml-i18n-tools package:
Version 0.32.1
* Deprecate --pass-through option, default to UTF-8 for anything
except RFC822 files
-- bug #145017 (Danilo Segan)
* Add support for .icon files
-- bug #157412 (Takao Fujiwara, Rodney Dawes)
Version 0.32
* Check to avoid whining about {arch} and $PACKAGE-$VERSION dist directories
when looking for files missing from POTFILES.in
-- bug #157278 (Rodney Dawes)
* Deprecate AC_PROG_INTLTOOL for IT_PROG_INTLTOOL
-- bug #151508 (Rodney Dawes)
* Add new INTLTOOL_XML_NOMERGE_RULE for translating XML files without
merging the translations back into the output XML file
-- bug #155842 (Rodney Dawes)
* Fix new Makefile.in.in stuff to work with automake 1.4
-- bug #157298 (Rodney Dawes)
* Update I18N-HOWTO for the changes to use our own Makefile.in.in
-- bug #79598 (Rodney Dawes)
* Allow use of either AM_GNU_GETTEXT or AM_GLIB_GNU_GETTEXT and use our
own Makefile.in.in instead of trying to patch one
-- bug #144715 (Rodney Dawes)
* Handle all supported gettext escape sequences in PO files
-- bug #48489 (Danilo Segan)
* Fix Scheme string extraction, add support for translators' comments
-- bug #137029 (Danilo Segan)
* Fix translations of attributes of XML elements
-- bug #155843 (Danilo Segan)
* Support for translators' comments in Glade files
-- bug #155294 (Danilo Segan)
* Fix paths and quoting for intltool script variables in intltool.m4
-- bug #154717 (James Henstridge, Rodney Dawes)
* Fix merging of xml:space="preserve" tags
-- bug #151017 (Danilo Segan).
* Look for Q_() keyword as well
-- bug #154063 (Danilo Segan).
Framework.
Spoon is an Application Framework that is designed primarily for
building Social Software web applications. Spoon::Base is the primary
base class for all the Spoon::* modules. Spoon.pm inherits from
Spiffy.pm. Spoon is not an application in and of itself. You need
to build your own applications from it.
needed to install the module. Packages that require plugins from the
Template Toolkit should depend on modules needed to make those plugins
function. Bump the PKGREVISION of p5-Template-Toolkit to 3.
For the packages that depend directly on p5-Template-Toolkit, add as
dependencies all of the packages needed to make the plugins work to
the package Makefiles, and bump their PKGREVISIONs.
IO::All combines all of the best Perl IO modules into a single Spiffy
object oriented interface to greatly simplify your everyday Perl IO
idioms. It exports a single function called "io", which returns a
new IO::All object. And that object can do it all!
The IO::All object is a proxy for IO::File, IO::Dir, IO::Socket,
IO::String, Tie::File, File::Spec, File::Path and File::ReadBackwards;
as well as all the DBM and MLDBM modules. You can use most of the
methods found in these classes and in IO::Handle (which they inherit
from). IO::All adds dozens of other helpful idiomatic methods including
file stat and manipulation functions.
"Spiffy" is a framework and methodology for doing object oriented (OO)
programming in Perl. Spiffy combines the best parts of Exporter.pm,
base.pm, mixin.pm and SUPER.pm into one magic foundation class. It
attempts to fix all the nits and warts of traditional Perl OO, in a
clean, straightforward and (perhaps someday) standard way.
While here, convert to options.mk.
GnuPG 1.4 Highlights
====================
This is a brief overview of the changes between the GnuPG 1.2 series
and the new GnuPG 1.4 series. To read the full list of highlights for
each revision that led up to 1.4, see the NEWS file in the GnuPG
distribution. This document is based on the NEWS file, and is thus
the highlights of the highlights.
When upgrading, note that RFC-2440, the OpenPGP standard, is currently
being revised. Most of the revisions in the latest draft (2440bis-12)
have already been incorporated into GnuPG 1.4.
Algorithm Changes
-----------------
OpenPGP supports many different algorithms for encryption, hashing,
and compression, and taking into account the OpenPGP revisions, GnuPG
1.4 supports a slightly different algorithm set than 1.2 did.
The SHA256, SHA384, and SHA512 hashes are now supported for read and
write.
The BZIP2 compression algorithm is now supported for read and write.
Due to the recent successful attack on the MD5 hash algorithm
(discussed in <http://www.rsasecurity.com/rsalabs/node.asp?id=2738>,
among other places), MD5 is deprecated for OpenPGP use. It is still
allowed in GnuPG 1.4 for backwards compatibility, but a warning is
given when it is used.
The TIGER/192 hash is no longer available. This should not be
interpreted as a statement as to the quality of TIGER/192 - rather,
the revised OpenPGP standard removes support for several unused or
mostly unused hashes, and TIGER/192 was one of them.
Similarly, Elgamal signatures and the Elgamal signing key type have
been removed from the OpenPGP standard, and thus from GnuPG. Please
do not confuse Elgamal signatures with DSA or DSS signatures or with
Elgamal encryption. Elgamal signatures were very rarely used and were
not supported in any product other than GnuPG. Elgamal encryption was
and still is part of OpenPGP and GnuPG.
Very old (pre-1.0) versions of GnuPG supported a nonstandard (contrary
to OpenPGP) Elgamal key type. While no recent version of GnuPG
permitted the generation of such keys, GnuPG 1.2 could still use them.
GnuPG 1.4 no longer allows the use of these keys or the (also
nonstandard) messages generated using them.
At build time, it is possible to select which algorithms will be built
into GnuPG. This can be used to build a smaller program binary for
embedded uses where space is tight.
Keyserver Changes
-----------------
GnuPG 1.4 does all keyserver operations via plugin or helper
applications. This allows the main GnuPG program to be smaller and
simpler. People who package GnuPG for various reasons have the
flexibility to include or leave out support for any keyserver type as
desired.
Support for fetching keys via HTTP and finger has been added. This is
mainly useful for setting a preferred keyserver URL like
"http://www.jabberwocky.com/key.asc". or "finger:wk at g10code.com".
The LDAP keyserver helper now supports storing, retrieving, and
searching for keys in both the old NAI "LDAP keyserver" as well as the
more recent method to store OpenPGP keys in standard LDAP servers.
This is compatible with the storage schema that PGP uses, so both
products can interoperate with the same LDAP server.
The LDAP keyserver helper is compatible with the PGP company's new
"Global Directory" service.
If the LDAP library you use supports LDAP-over-TLS and LDAPS, then
GnuPG detects this and supports them as well. Note that using TLS or
LDAPS does not improve the security of GnuPG itself, but may be useful
in certain key distribution scenarios.
HTTP Basic authentication is now supported for all HKP and HTTP
keyserver functions, either through a proxy or via direct access.
The HKP keyserver plugin supports the new machine-readable key
listing format for those keyservers that provide it.
IPv6 is supported for HKP and HTTP keyserver access.
When using a HKP keyserver with multiple DNS records (such as
subkeys.pgp.net which has the addresses of multiple servers around the
world), all DNS address records are tried until one succeeds. This
prevents a single down server in the rotation from stopping access.
DNS SRV records are used in HKP keyserver lookups to allow
administrators to load balance and select keyserver ports
automatically.
Timeout support has been added to the keyserver plugins. This allows
users to set an upper limit on how long to wait for the keyserver
before giving up.
Preferred Keyserver URL
-----------------------
Preferred keyserver support has been added. Users may set a preferred
keyserver via the --edit-key command "keyserver". If the
--keyserver-option honor-keyserver-url is set (and it is by default),
then the preferred keyserver is used when refreshing that key with
--refresh-keys.
The --sig-keyserver-url option can be used to inform signature
recipients where the signing key can be downloaded. When verifying
the signature, if the signing key is not present, and the keyserver
options honor-keyserver-url and auto-key-retrieve are set, this URL
will be used to retrieve the key.
Trust Signatures
----------------
GnuPG 1.4 supports OpenPGP trust signatures, which allow a user to
specify the trust level and distance from the user along with the
signature so users can delegate different levels of certification
ability to other users, possibly restricted by a regular expression on
the user ID.
Trust Models
------------
GnuPG 1.4 supports several ways of looking at trust:
Classic - The classic PGP trust model, where people sign each others
keys and thus build up an assurance (called "validity") that
the key belongs to the right person. This was the default
trust model in GnuPG 1.2.
Always - Bypass all trust checks, and make all keys fully valid.
Direct - Users may set key validity directly.
PGP - The PGP 7 and 8 behavior which combines Classic trust with trust
signatures overlaid on top. This is the default trust model in
GnuPG 1.4.
The OpenPGP Smartcard
---------------------
GnuPG 1.4 supports the OpenPGP smartcard
(<http://www.g10code.de/p-card.html>)
Secret keys may be kept fully or partially on the smartcard. The
smartcard may be used for primary keys or subkeys.
Other Interesting New Features
------------------------------
For those using Security-Enhanced Linux <http://www.nsa.gov/selinux/>,
the configure option --enable-selinux-support prevents GnuPG from
processing its own files (i.e. reading the secret keyring for
something other than getting a secret key from it). This simplifies
writing ACLs for the SELinux kernel.
Readline support is now available at all prompts if the system
provides a readline library.
GnuPG can now create messages that can be decrypted with either a
passphrase or a secret key. These messages may be generated with
--symmetric --encrypt or --symmetric --sign --encrypt.
--list-options and --verify-options allow the user to customize
exactly what key listings or signature verifications look like,
enabling or disabling things such as photo display, preferred
keyserver URL, calculated validity for each user ID, etc.
The --primary-keyring option designates the keyring that the user
wants new keys imported into.
The --hidden-recipient (or -R) command encrypts to a user, but hides
the identity of that user. This is the same functionality as
--throw-keyid, but can be used on a per-user basis.
Full algorithm names (e.g. "3DES", "SHA1", "ZIP") can now be used
interchangeably with the short algorithm names (e.g. "S2", "H2", "Z1")
anywhere algorithm names are used in GnuPG.
The --keyid-format option selects short (99242560), long
(DB698D7199242560), 0xshort (0x99242560), or 0xlong
(0xDB698D7199242560) key ID displays. This lets users tune the
display to what they prefer.
While it is not recommended for extended periods, it is possible to
run both GnuPG 1.2.x and GnuPG 1.4 during the transition. To aid in
this, GnuPG 1.4 tries to load a config file suffixed with its version
before it loads the default config file. For example, 1.4 will try
for gpg.conf-1.4 and gpg.conf-1 before falling back to the regular
gpg.conf file.
too numerous to be listed here, but include adding a new DES API
(support for the old one is still present).
Changes to the pkgsrc structure include:
* Install the shared libraries with a version number that matches the
OpenSSL version number
* Move some of the less often-used c_* utilities back into the examples
directory.
* Drop support for using the RSAREF library and always use the built-in
RSA code instead.
(it currently affects packages using X11, but I guess it will also cause
problems when using pkgviews, for example).
So, instead of fixing it on a package basis, create some wrappers in the
buildlink directory that parse CFLAGS and LDFLAGS contents and convert them
to ocaml flags (basically, prepend -ccopt to each of them).
X11 libraries.
I suspect this was not noticed before because the whole ocaml was linked
against these libraries, so they were pulled in at runtime anyway.
