Re: [gentoo-dev] New mysql eclasses review
Hi.
On 18-04-2011 23:02, Ulrich Mueller wrote:
>> On Mon, 18 Apr 2011, Jorge Manuel B S Vicetto wrote:
>
>> The mysql team now uses 3 eclasses: mysql-v2.eclass[2] (base
>> eclass), mysql-autotools.eclass[3] (for autotools based releases)
>> and mysql-cmake.eclass[4] (for cmake based releases). The first 2
>> eclasses are complete, pending any updates from the review. The
>> mysql-cmake eclass is still under development, but can also benefit
>> from a review.
>
> I didn't go through all of it, but here are a few things that I've
> noticed in mysql-v2.eclass:
Thank you Ulrich for the review.
I'm attaching the diff to this email, but the commitdiff can also be
seen in the overlay -
http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commitdiff;h=7cd4cedb1dcade2a63018fc82a2622606c524126
>> # @ECLASS: mysql.eclass
>
> Shouldn't this match the filename of the eclass? (Same for
> mysql-autotools.eclass.)
Fixed.
>> # @DESCRIPTION:
>> # The mysql.eclass provides almost all the code to build the mysql ebuilds
>> # including the src_unpack, src_prepare, src_configure, src_compile,
>> # scr_install, pkg_preinst, pkg_postinst, pkg_config and pkg_postrm
>> # phase hooks.
>
> Name of the eclass should be updated.
Fixed.
>> MYSQL_EXPF="src_unpack src_compile src_install"
>> case "${EAPI:-0}" in
>> 2|3|4) MYSQL_EXPF+=" src_prepare src_configure" ;;
>> *) die "Unsupported EAPI: ${EAPI}" ;;
>> esac
>
>> EXPORT_FUNCTIONS ${MYSQL_EXPF}
>
> You don't need a global variable here:
> ,
> | EXPORT_FUNCTIONS src_unpack src_compile src_install
> | case "${EAPI:-0}" in
> | 2|3|4) EXPORT_FUNCTIONS src_prepare src_configure ;;
> | *) die "Unsupported EAPI: ${EAPI}" ;;
> | esac
> `
>
> or even:
> ,
> | case "${EAPI:-0}" in
> | 2|3|4) ;;
> | *) die "Unsupported EAPI: ${EAPI}" ;;
> | esac
> | EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile
> src_install
> `
I was following base.eclass example, but switched to the last
alternative you presented.
>> # @ECLASS-VARIABLE: XTRADB_VER
>> # @DESCRIPTION:
>> # Version of the XTRADB storage engine
>> XTRADB_VER="${XTRADB_VER}"
>
> Is this assignment needed, or could you use @DEFAULT_UNSET instead?
> (Assuming it's for the eclass manpage.) Same for other variables.
Did you mean using ": ${XTRADB_VER:=}"? Done.
>> # Having different flavours at the same time is not a good idea
>> for i in "mysql" "mysql-community" "mysql-cluster" "mariadb" ; do
>> [[ "${i}" == ${PN} ]] ||
>
> Quotes are not necessary here.
Fixed.
>> pbxt_patch_available \
>> && PBXT_P="pbxt-${PBXT_VERSION}" \
>> && PBXT_SRC_URI="http://www.primebase.org/download/${PBXT_P}.tar.gz
>> mirror://sourceforge/pbxt/${PBXT_P}.tar.gz" \
>> && SRC_URI="${SRC_URI} pbxt? ( ${PBXT_SRC_URI} )" \
>
>> # PBXT_NEWSTYLE means pbxt is in storage/ and gets enabled as other plugins
>> # vs. built outside the dir
>> pbxt_available \
>> && IUSE="${IUSE} pbxt" \
>> && mysql_version_is_at_least "5.1.40" \
>> && PBXT_NEWSTYLE=1
>
>> xtradb_patch_available \
>> && XTRADB_P="percona-xtradb-${XTRADB_VER}" \
>> && XTRADB_SRC_URI_COMMON="${PERCONA_VER}/source/${XTRADB_P}.tar.gz" \
>> && XTRADB_SRC_B1="http://www.percona.com/"; \
>> && XTRADB_SRC_B2="${XTRADB_SRC_B1}/percona-builds/" \
>> &&
>> XTRADB_SRC_URI1="${XTRADB_SRC_B2}/Percona-Server/Percona-Server-${XTRADB_SRC_URI_COMMON}"
>> \
>> && XTRADB_SRC_URI2="${XTRADB_SRC_B2}/xtradb/${XTRADB_SRC_URI_COMMON}" \
>> && XTRADB_SRC_URI3="${XTRADB_SRC_B1}/${PN}/xtradb/${XTRADB_SRC_URI_COMMON}" \
>> && SRC_URI="${SRC_URI} xtradb? ( ${XTRADB_SRC_URI1} ${XTRADB_SRC_URI2}
>> ${XTRADB_SRC_URI3} )" \
>> && IUSE="${IUSE} xtradb"
>
> Probably a matter of taste, but I'd use "if" blocks instead of the
> multiple && here.
I switched to if blocks here.
>> mv --strip-trailing-slashes -T
>> "${old_MY_DATADIR_s}" "${MY_DATADIR_s}" \
>
> Both options --strip-trailing-slashes and -T are GNUisms and may not
> exist on other userlands (like BSD).
I'll let Robin take a look at this one.
> Ulrich
--
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
diff --git a/dev-db/mysql/Manifest b/dev-db/mysql/Manifest
index a76baf5..99f845f 100644
--- a/dev-db/mysql/Manifest
+++ b/dev-db/mysql/Manifest
@@ -11,6 +11,7 @@ DIST mysql-5.1.52.tar.gz 23841760 RMD160
5809c7a5932a014fe412ddc5b9f15632c7367c2
DIST mysql-5.1.53.tar.gz 23871815 RMD160
e8fd69450dda85cf3f41269e6e3fca05caccc76d SHA1
24064a4c0f8b88b30acb6ddb03f32e897ef061f3 SHA256
d68c0db580bb514bb1759d4c69dc71ceb0e3573ac88a1025111bdd8f89e234a4
DIST mysql-5.1.56.tar.gz 24795624 RMD160
c2ff6eb06d0797d4b56630b783d4ad2d1add1422 SHA1
8665c76ab4ab36e8d2379ddf6d678c89b95d9321 SHA256
930e731c8f9318aa3f5e2e6985f6776aaaec81cd32df310e79e73d87177f6613
DIST mysql-5.5.10.tar.gz 23877968 RMD160
7f190513e38bbbcac21291e226de87b3b95a1ba4 SHA1
7e0b426d7a9ef0eaa6e2b2ea3e5fef1e1a078c5d SHA256
Re: [gentoo-dev] New mysql eclasses review
> On Wed, 20 Apr 2011, Jorge Manuel B S Vicetto wrote:
>>> # @ECLASS-VARIABLE: XTRADB_VER
>>> # @DESCRIPTION:
>>> # Version of the XTRADB storage engine
>>> XTRADB_VER="${XTRADB_VER}"
>>
>> Is this assignment needed, or could you use @DEFAULT_UNSET instead?
>> (Assuming it's for the eclass manpage.) Same for other variables.
> Did you mean using ": ${XTRADB_VER:=}"? Done.
No, I meant the @DEFAULT_UNSET marker from eclass-manpages:
Ulrich
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
2011/4/19 Tomáš Chvátal : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dne 16.4.2011 08:29, Corentin Chary napsal(a): >> New website is up and running at >> >> http://euscan.iksaif.net/ >> >> The git tree is still at http://git.iksaif.net/?p=euscan.git;a=summary >> >> TODO: >> - Make some charts to see how it's going >> - Finish the "scan my world" feature >> - Add a way to subsribe to herds/maintainer/packages in order to >> receive weekly/monthly reports >> >> I'll gladly accept any patch ! :) >> > Hello found another issue, > > http://euscan.iksaif.net/package/media-video/kmplayer/ > > 0.11.2c IS newer than 0.11.2 :) > > Cheers Should be fixed this evening. I'll now use portage.vercmp() by default, and fallback to pkg_resources. Thanks for the report. -- Corentin Chary http://xf.iksaif.net
[gentoo-dev] rfc: openrc use flag
All, This bug [1] brings up an issue that I would like thoughts about. sys-fs/udev and net-wireless/bluez, among other packages, install udev rules which assume that you are using openrc. On systems where openrc is not used in the boot process, this causes issues because openrc services are run by the udev rules even though openrc did not boot the system. The author of the bug feels that the way to fix this is for us to put a check in openrc that makes it refuse to run services if it was not used in the boot process. This may work; however, I do not feel that it addresses the root cause of the bug. I feel that the root cause is packages unconditionally installing udev rules which assume everyone uses openrc. My proposal is to give these packages an "openrc" use flag which will control whether or not openrc specific support will be installed. This would be on by default, of course, since most of us use openrc. The author of the bug is correct about the disadvantage of doing this -- if you want to switch on or off openrc support, this will require a rebuild of the affected packages. I feel that the advantage of this approach outweighs this disadvantage because this approach allows the user to tell udev not to even attempt to run openrc services, and this will lead to a more efficient system. Any input would be appreciated. William [1] http://bugs.gentoo.org/show_bug.cgi?id=364159 pgpbgddVWkL4N.pgp Description: PGP signature
Re: [gentoo-dev] rfc: openrc use flag
В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > The author of the bug feels that the way to fix this is for us to put a > check in openrc that makes it refuse to run services if it was not used > in the boot process. This is good idea to have in any case since I remember my system went crazy after I've tried to start some service inside chroot. > This may work; however, I do not feel that it addresses the root cause > of the bug. I feel that the root cause is packages unconditionally > installing udev rules which assume everyone uses openrc. I'd voted to have both implemented. -- Peter.
Re: [gentoo-dev] rfc: openrc use flag
El mié, 20-04-2011 a las 22:02 +0400, Peter Volkov escribió: > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > The author of the bug feels that the way to fix this is for us to put a > > check in openrc that makes it refuse to run services if it was not used > > in the boot process. > > This is good idea to have in any case since I remember my system went > crazy after I've tried to start some service inside chroot. > > > This may work; however, I do not feel that it addresses the root cause > > of the bug. I feel that the root cause is packages unconditionally > > installing udev rules which assume everyone uses openrc. > > I'd voted to have both implemented. > I would vote for the first one, I still don't like "openrc" USE flag approach much because: 1. Would need to rebuild some packages when switching between init systems. 2. I remember (from "logrotate" USE flag case) that using an USE flag for simply installing or not a file is not usually preferred :-/ Best regards signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: openrc use flag
On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote: > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > The author of the bug feels that the way to fix this is for us to put a > > check in openrc that makes it refuse to run services if it was not used > > in the boot process. > > This is good idea to have in any case since I remember my system went > crazy after I've tried to start some service inside chroot. My concern about it though is prefix installs. If I implement something like this, will it not break openrc on prefix systems? William pgphpAAbe8eMt.pgp Description: PGP signature
Re: [gentoo-dev] rfc: openrc use flag
On Wed, 20 Apr 2011 13:22:53 -0500
William Hubbs wrote:
> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
> > > The author of the bug feels that the way to fix this is for us to
> > > put a check in openrc that makes it refuse to run services if it
> > > was not used in the boot process.
> >
> > This is good idea to have in any case since I remember my system
> > went crazy after I've tried to start some service inside chroot.
>
> My concern about it though is prefix installs. If I implement
> something like this, will it not break openrc on prefix systems?
I'm attaching the patch I suggested to fix the issue.
It is based on the assumption that in order to run cleanly, OpenRC
needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark all services
stopped). It assumes that the basic effect of a running OpenRC
is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.
I tested that approach with clean OpenRC and systemd installs, and it
doesn't create any issues. I'd appreciate if someone with Prefix system
could test it as well.
--
Best regards,
Michał Górny
From ac70101ad50348fee636cea36cefcd473ee45690 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=
Date: Wed, 20 Apr 2011 15:34:08 +0200
Subject: [PATCH] Add a check for softlevel when running init.d scripts.
${RC_SVCDIR}/softlevel should be a good file to check for before running
a OpenRC script. This should fix http://bugs.gentoo.org/show_bug.cgi?id=364159.
---
src/rc/runscript.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/rc/runscript.c b/src/rc/runscript.c
index 0eca487..b7cc810 100644
--- a/src/rc/runscript.c
+++ b/src/rc/runscript.c
@@ -1112,6 +1112,11 @@ runscript(int argc, char **argv)
exit(EXIT_FAILURE);
}
+ if (!exists(RC_SVCDIR "/softlevel")) {
+ fprintf(stderr, "OpenRC is not running\n");
+ exit(EXIT_FAILURE);
+ }
+
if (stat(argv[1], &stbuf) != 0) {
fprintf(stderr, "runscript `%s': %s\n",
argv[1], strerror(errno));
--
1.7.5.rc1
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: openrc use flag
On 20-04-2011 13:22:53 -0500, William Hubbs wrote: > On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote: > > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > > The author of the bug feels that the way to fix this is for us to put a > > > check in openrc that makes it refuse to run services if it was not used > > > in the boot process. > > > > This is good idea to have in any case since I remember my system went > > crazy after I've tried to start some service inside chroot. > > My concern about it though is prefix installs. If I implement something > like this, will it not break openrc on prefix systems? does such thing exist? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] openrc portage news item
On 13:32 Thu 14 Apr , Kfir Lavi wrote: > When i run world update, I usually don't really check all the written > stuff. > > If I do this, I'm sure a lot more Gentoo users do the same. So do > expect people rebooting the machine without checking what your have > wrote. This can be a major headache if you have few systems that are > doing auto updates. I would solve this issue by stopping the emerge > and getting the attention of the user. If I don't get the attention of > the user, no openrc will be installed. It should be something like > emerge -C ... 1 .2 3 4 5... > > To conclude, you can't issue such a change without proper confirmation from > the user. I know this is the case. You're going to get literally thousands of people (or more) who break their Gentoo systems if that indeed is the consequence of not reading the migration guide and doing some action. From a glance over the guide, it wasn't immediately obvious what in there would result in a broken system. Perhaps it's the "run dispatch-conf" that's buried in the middle of a paragraph without enough emphasis? That's particularly confusing for people who use etc-update instead, and it *needs* to move somewhere more obvious like a separate code listing with big tags and bold text. The line of red text just isn't enough, it needs to stand out even more. It seems like nobody's really clear on what exactly happens though, since I've seen people talking about this *maybe* resulting in an unbootable system. Has anyone tested it? One potential cleaner approach to the same idea Kfir suggested is to make it an interactive emerge with an ACCEPT_LICENSE-like feature that pops up something you must read and agree to. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpNuizXUZtxY.pgp Description: PGP signature
Re: [gentoo-dev] openrc portage news item
On Wed, 20 Apr 2011 20:12:21 -0500
Donnie Berkholz wrote:
> From a glance over the guide, it wasn't immediately obvious what in
> there would result in a broken system. Perhaps it's the "run
> dispatch-conf" that's buried in the middle of a paragraph without
> enough emphasis? That's particularly confusing for people who use
> etc-update instead, and it *needs* to move somewhere more obvious
> like a separate code listing with big tags and bold text.
> The line of red text just isn't enough, it needs to stand out even
> more.
I have converted all my systems to baselayout-2/openrc now, and on all
of them, the very /last/ message shown after the emerge run is that "[x]
important configuration files [in /etc]" need to be updated.
I would think that Gentoo users are already primed to this message and
that they would respond accordingly. Even when it's dozens of packages
you have updated, this message should stand out, because it's basically
the first one you read scrolling back up.
> One potential cleaner approach to the same idea Kfir suggested is to
> make it an interactive emerge with an ACCEPT_LICENSE-like feature
> that pops up something you must read and agree to.
I've been thinking about an openrc mechanism that refuses rebooting
(reboot, halt, which are calls that openrc handles)
when /etc/{conf,init}.d files have not been updated. Anyone game to get
coding? :)
jer
Re: [gentoo-dev] rfc: openrc use flag
On Wed, 20 Apr 2011 22:02:41 +0400 Peter Volkov wrote: > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > The author of the bug feels that the way to fix this is for us to > > put a check in openrc that makes it refuse to run services if it > > was not used in the boot process. Why refuse? It could instead assume it needed to only start a service in, say, a chroot, like ssh or apache2, without assuming anything else needs to be done. If the service needed anything else, it could be left to fail on its own terms. > This is good idea to have in any case since I remember my system went > crazy after I've tried to start some service inside chroot. Basically, baselayout/openrc (baselayout-1 has the same problem) would (try to) shut down your system because it thought something was terribly wrong. That's bitten me as well when I still thought I could test services inside a chroot. > > This may work; however, I do not feel that it addresses the root > > cause of the bug. I feel that the root cause is packages > > unconditionally installing udev rules which assume everyone uses > > openrc. How should the udev rules be changed to match /any/ init system? jer
Re: [gentoo-dev] openrc portage news item
On Thu, 21 Apr 2011 04:23:19 +0200 Jeroen Roovers wrote: > I have converted all my systems to baselayout-2/openrc now, and on all > of them, the very /last/ message shown after the emerge run is that > "[x] important configuration files [in /etc]" need to be updated. > > I would think that Gentoo users are already primed to this message and > that they would respond accordingly. Even when it's dozens of packages > you have updated, this message should stand out, because it's > basically the first one you read scrolling back up. Adding to that, the appropriate response is to not file a bug report or complain otherwise, but to bow your head in shame, bring the system up with some kind of boot medium and chroot in to run your favourite /etc updating tool, then reboot cleanly and be running again. jer
Re: [gentoo-dev] rfc: openrc use flag
On Thu, Apr 21, 2011 at 04:31:46AM +0200, Jeroen Roovers wrote: > On Wed, 20 Apr 2011 22:02:41 +0400 > Peter Volkov wrote: > > > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > > The author of the bug feels that the way to fix this is for us to > > > put a check in openrc that makes it refuse to run services if it > > > was not used in the boot process. > > Why refuse? It could instead assume it needed to only start a service > in, say, a chroot, like ssh or apache2, without assuming anything else > needs to be done. If the service needed anything else, it could be > left to fail on its own terms. This might be possible; I would just change the message in the patch provided to something like, "Warning, openrc did not boot this system, so you may get unpredictable results.\n" > > This is good idea to have in any case since I remember my system went > > crazy after I've tried to start some service inside chroot. > > Basically, baselayout/openrc (baselayout-1 has the same problem) would > (try to) shut down your system because it thought something was > terribly wrong. That's bitten me as well when I still thought I could > test services inside a chroot. > > > > This may work; however, I do not feel that it addresses the root > > > cause of the bug. I feel that the root cause is packages > > > unconditionally installing udev rules which assume everyone uses > > > openrc. > > How should the udev rules be changed to match /any/ init system? For an example of the problem, take a look on your system at /lib/udev/rules.d/90-network.rules. This is part of openrc's hotplug functionality. Basically it tries to run /etc/init.d/net.$INTERFACE start when a network interface is added to the system and rc_hotplug allows it. In net-wireless/bluez, you will see similar integration between openrc and udev. Once bluez is installed, /lib/udev/rules.d/70-bluetooth.rules runs bluetooth.sh which tries to run a service in /etc/init.d. To make things work with /any/ init system, the best way to go would be to make it a practice not to run services from within udev rules or external run scripts like net.sh and bluetooth.sh in /lib/udev. William pgpxxqE40HLZO.pgp Description: PGP signature
[gentoo-dev] Re: rfc: openrc use flag
Michał Górny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excerpted:
> On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs
> wrote:
>
>> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
>> > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет:
>> > > The author of the bug feels that the way to fix this is for us to
>> > > put a check in openrc that makes it refuse to run services if it
>> > > was not used in the boot process.
>> >
>> > This is good idea to have in any case since I remember my system went
>> > crazy after I've tried to start some service inside chroot.
>>
>> My concern about it though is prefix installs.
>
> [The attached patch] is based on the assumption that in order to run
> cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark
> all services stopped). It assumes that the basic effect of a running
> OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.
>
> I tested that approach with clean OpenRC and systemd installs, and it
> doesn't create any issues. I'd appreciate if someone with Prefix system
> could test it as well.
> http://bugs.gentoo.org/show_bug.cgi?id=364159.
The patch seems reasonable, but I can't but think that there's likely
corner-cases that may be unknown ATM that could complicate things. If we
establish a slightly broader base now, it can be reasonably expanded in
the future.
What about handling this much the same as subsystem-type auto-detection
was ultimately handled, but controlling how much of openrc should run:
1) Auto: (like rc_sys being commented out). This would do the auto-detect
thing using something like the suggested softlevel file detection patch.
2) On: Openrc is locked ON, and will try to handle everything. This
could be the default (much like rc_sys="").
3) Off: Openrc is locked OFF, and will immediately terminate as soon as it
loads the config far enough to see that it is OFF, if anything attempts to
run it.
4) Later? Nodep: (Target stable-next?) If the setting is "nodep", openrc
should assume all deps are met and simply run the script it is asked to
run, only.
5) Optionally, service.allowed: (Target bluesky?) Another setting could
list specific services that openrc should be allowed to run. If
service.allowed isn't empty/unset, anything not listed would not be run.
Nodep mode would be altered slightly by this, in that any listed service
could be depended normally, while anything not listed would be assumed to
be dependency-met. Normal (auto/on) mode would work in the reverse for
anything not listed. Since openrc isn't allowed to touch those services
but is operating in normal dependency mode, to openrc they'd not exist and
therefore block the start of any depending services as well.
6) Optionally, service.provided: To go along with #5, for openrc in normal
mode, it could borrow the "package.provided" concept from portage, making
it "service.provided". For normal mode, services listed in this third
setting, but ONLY these services, would be assumed to be met much as if
openrc was operating in nodeps mode. Services not in this list would be
treated as above. (This would allow openrc to nodep on services in
service.provided, while failing OTHER deps not found in service.allowed,
if service.allowed isn't empty/unset.
7) Optionally, service.blacklisted. This would be the negative version of
#5. Presumably, if both service.allowed AND service.blacklisted are set
and non-empty, one would take precedence and the other would be ignored
(with documentation as to which was which).
Obviously #5-7 are wish-list, not really appropriate for our current
target-stable. However, *if* they were thought sufficiently useful to
code up, these features could appear with a later version.
At least #1-3 should be quite easy to code and appropriate for stable,
since the config concept and implementation has already been tested to
some degree with the current but quite new subsystem-type implementation.
#4 falls in the middle. I threw it in based on jer's suggestion, which
I'd like to see even if #5-7 aren't implemented, but it's a big enough
feature-add that it really should have additional testing. As such I don't
see it for current-stable-target, but perhaps stable-next?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
