Bug#903392: Bug#931253: Bug#903392: want support for packaging-only maintainer views
Hello, On Sun 30 Jun 2019 at 10:01PM +01, Ian Jackson wrote: >> I no longer think that renaming is needed. I'd like to suggest adding >> baredebian+git as an alias for baredebian, and writing it immediately >> after in the docs, i.e. >> >> --quilt=baredebian (or its alias --quilt=baredebian+git) specifies >> that ... >> >> I think that this makes it easier to understand the difference between >> the two options, but also it enhances the strength of the encouragement >> to use baredebian+git over baredebian+tarball. > > I can do that. One of the two values must be primary in that it will > be the value of $quilt_mode and appear in messages. So if you say > --baredebian+git > you will get messages which say you specified "-quilt=baredebian". > I hope that will be OK. That seems fine to me. -- Sean Whitton signature.asc Description: PGP signature
Bug#903392: Bug#931253: Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Bug#903392: Bug#931253: Bug#903392: want support for
packaging-only maintainer views"):
> While writing the e-mail I sent a few minutes ago, I lost track of the
> actual concrete suggestion, which was calling baredebian+git just
> baredebian. Sorry about that.
Heh.
> I no longer think that renaming is needed. I'd like to suggest adding
> baredebian+git as an alias for baredebian, and writing it immediately
> after in the docs, i.e.
>
> --quilt=baredebian (or its alias --quilt=baredebian+git) specifies
> that ...
>
> I think that this makes it easier to understand the difference between
> the two options, but also it enhances the strength of the encouragement
> to use baredebian+git over baredebian+tarball.
I can do that. One of the two values must be primary in that it will
be the value of $quilt_mode and appear in messages. So if you say
--baredebian+git
you will get messages which say you specified "-quilt=baredebian".
I hope that will be OK.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: Bug#931253: Bug#903392: want support for packaging-only maintainer views
Hello, On Sun 30 Jun 2019 at 12:44PM +01, Ian Jackson wrote: > Please take a look at wip.baredebian in my chiark repo and see what > you think of the way the docs read now. > > If after reading that you still think it ought to be renamed, I will > do so. While writing the e-mail I sent a few minutes ago, I lost track of the actual concrete suggestion, which was calling baredebian+git just baredebian. Sorry about that. I no longer think that renaming is needed. I'd like to suggest adding baredebian+git as an alias for baredebian, and writing it immediately after in the docs, i.e. --quilt=baredebian (or its alias --quilt=baredebian+git) specifies that ... I think that this makes it easier to understand the difference between the two options, but also it enhances the strength of the encouragement to use baredebian+git over baredebian+tarball. -- Sean Whitton signature.asc Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Hello,
On Sat 29 Jun 2019 at 03:43PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
> maintainer views"):
>> On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
>> > Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
>> > maintainer views"):
>> >> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
>> >> > Secondly:
>> >> >
>> >> > If the user says "use upstream from git" but there is no git, the user
>> >> > gets an error message mentioning git tags and that can also say
>> >> > something about the other quilt mode.
>> >> >
>> >> > If the user says "use upstream tarball" but they had git available,
>> >> > the result is to silently ignore the upstream history and use a
>> >> > tarball import instead.
>> >> >
>> >> > In keeping with the philosophy of making doing the right thing
>> >> > convenient, suboptimals things possible, and requiring mistakes to be
>> >> > explicit, ISTM that the tarball variant should mention that.
>> >>
>> >> "mention that"? Sorry, I'm not sure about how what you say here is a
>> >> response to what I wrote.
>> >
>> > I mean, the name for the tarball variant should mention tarball.
>>
>> Okay. I do not think what you've written is right, if I'm properly
>> understanding its implications. You seem to be suggesting that
>> baredebian+git is better than baredebian+tarball, in the sense that the
>> latter is a fallback when an upstream git tag is not available. I do
>> not think that is how people who use baredebian+tarball think of their
>> workflow.
>>
>> Perhaps I'm just misunderstanding what you're trying to say.
>
> No, I mean that there is a risk of dgit accidentally and unnecessarily
> using a worse quilt mode, due to user error.
I agree that we should try to avoid this if we can do that without
getting in other people's way.
>> I think it should be renamed. Otherwise, it might unhelpfully imply
>> that the dgit developers think that baredebian+git is better than
>> baredebian+tarball in some way.
>
> But we do. I agree we don't want to make value judgements about this
> kind of thing unnecessarily, but:
>
> baredebian+tarball will always work, whereas baredebian+git will
> sometimes fail (wrong git tag, git tag contents are wrong).
>
> People will generally think that it is better to use an option which
> will always work, rather than one which might fail for additional
> reasons.
>
> Or to put it another way: users who need +tarball need it and do not
> have a choice.
>
> Users who can use +git need to be told that +git is better thaj
> +tarball because it (i) publishes upstream git history
> (ii) double checks that their package is sane.
>
> Does that make sense ?
Yes, I think I understand what you want to achieve here, and I see what
you mean about people possibly just using baredebian+tarball because
they know it will always work.
Nevertheless, I am concerned that the cost of building this into dgit's
behaviour might be too high. There are people that think
baredebian+tarball is better than baredebian+git. They are going to be
turned off dgit pretty fast if they feel pushed towards using
baredebian+git by the behaviour of the actual tool, rather than just
what we say in its docs. But we really want those people to be using
`dgit push-source` for their uploads.
I.e. I don't think that there should be anything else required, other
than setting the quilt mode to baredebian+tarball, in order to have dgit
ignore any upstream tags. It would seem to go against the dgit design
goal that no-one has to change their workflow.
So how about this. baredebian+tarball prints a prominent warning
message if it thinks that baredebian+git would work, suggesting that the
user look at the docs, where they can read under baredebian+git why it's
better, and under baredebian+tarball what we think the disadvantages
are. The warning can come close to the end of dgit's output.
The user will probably see this warning when they use `dgit sbuild` or
similar. In the worst case, they'll see the warning only when it's too
late, because they're in the middle of a dgit push, but that's unlikely
to be the first time they see it.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#931253: Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Bug#931253: Bug#903392: want support for packaging-only
maintainer views"):
> On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
> > I could make baredebian+git an alias for it. Or, rename it. It's not
> > released yet...
>
> I think it should be renamed. Otherwise, it might unhelpfully imply
> that the dgit developers think that baredebian+git is better than
> baredebian+tarball in some way.
Please take a look at wip.baredebian in my chiark repo and see what
you think of the way the docs read now.
If after reading that you still think it ought to be renamed, I will
do so.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
maintainer views"):
> On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
> > Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
> > maintainer views"):
> >> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
> >> > Secondly:
> >> >
> >> > If the user says "use upstream from git" but there is no git, the user
> >> > gets an error message mentioning git tags and that can also say
> >> > something about the other quilt mode.
> >> >
> >> > If the user says "use upstream tarball" but they had git available,
> >> > the result is to silently ignore the upstream history and use a
> >> > tarball import instead.
> >> >
> >> > In keeping with the philosophy of making doing the right thing
> >> > convenient, suboptimals things possible, and requiring mistakes to be
> >> > explicit, ISTM that the tarball variant should mention that.
> >>
> >> "mention that"? Sorry, I'm not sure about how what you say here is a
> >> response to what I wrote.
> >
> > I mean, the name for the tarball variant should mention tarball.
>
> Okay. I do not think what you've written is right, if I'm properly
> understanding its implications. You seem to be suggesting that
> baredebian+git is better than baredebian+tarball, in the sense that the
> latter is a fallback when an upstream git tag is not available. I do
> not think that is how people who use baredebian+tarball think of their
> workflow.
>
> Perhaps I'm just misunderstanding what you're trying to say.
No, I mean that there is a risk of dgit accidentally and unnecessarily
using a worse quilt mode, due to user error.
That is I think baredebian+tarball is inferior to the +git version,
but the latter cannot always be used (depending on the user's prior
choices, we we are not - here - trying to influence).
> > I could make baredebian+git an alias for it. Or, rename it. It's not
> > released yet...
>
> I think it should be renamed. Otherwise, it might unhelpfully imply
> that the dgit developers think that baredebian+git is better than
> baredebian+tarball in some way.
But we do. I agree we don't want to make value judgements about this
kind of thing unnecessarily, but:
baredebian+tarball will always work, whereas baredebian+git will
sometimes fail (wrong git tag, git tag contents are wrong).
People will generally think that it is better to use an option which
will always work, rather than one which might fail for additional
reasons.
Or to put it another way: users who need +tarball need it and do not
have a choice.
Users who can use +git need to be told that +git is better thaj
+tarball because it (i) publishes upstream git history
(ii) double checks that their package is sane.
Does that make sense ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Hello,
On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
> Control: clone -1 -2
> Control: retitle -2 want bare-debian tarball-orig quilt mode
> Control: tags -2 - pending
>
> Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
> maintainer views"):
>> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
>> > Secondly:
>> >
>> > If the user says "use upstream from git" but there is no git, the user
>> > gets an error message mentioning git tags and that can also say
>> > something about the other quilt mode.
>> >
>> > If the user says "use upstream tarball" but they had git available,
>> > the result is to silently ignore the upstream history and use a
>> > tarball import instead.
>> >
>> > In keeping with the philosophy of making doing the right thing
>> > convenient, suboptimals things possible, and requiring mistakes to be
>> > explicit, ISTM that the tarball variant should mention that.
>>
>> "mention that"? Sorry, I'm not sure about how what you say here is a
>> response to what I wrote.
>
> I mean, the name for the tarball variant should mention tarball.
Okay. I do not think what you've written is right, if I'm properly
understanding its implications. You seem to be suggesting that
baredebian+git is better than baredebian+tarball, in the sense that the
latter is a fallback when an upstream git tag is not available. I do
not think that is how people who use baredebian+tarball think of their
workflow.
Perhaps I'm just misunderstanding what you're trying to say.
I do think, to be clear, that we should just use 'baredebian+git' and
'baredebian+tarball' and have there be no 'baredebian' splitting quilt
mode.
>> >> An alternative to 'packaging' would be 'debiandir'.
>> >
>> > In my new taxonomy, I call this "bare debian" so baredebian would be a
>> > possibility.
>> >
>> > I think quilt modes could contain + signs so perhaps
>> >baredebian+git
>> >baredebian+tarball
>>
>> This, or debiandir+git and debiandir+tarball, LGTM.
>
> So far I have implemented `baredebian' to mean the with-upstream-git
> variant.
>
> I could make baredebian+git an alias for it. Or, rename it. It's not
> released yet...
I think it should be renamed. Otherwise, it might unhelpfully imply
that the dgit developers think that baredebian+git is better than
baredebian+tarball in some way.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Control: clone -1 -2
Control: retitle -2 want bare-debian tarball-orig quilt mode
Control: tags -2 - pending
Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
maintainer views"):
> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
> > Secondly:
> >
> > If the user says "use upstream from git" but there is no git, the user
> > gets an error message mentioning git tags and that can also say
> > something about the other quilt mode.
> >
> > If the user says "use upstream tarball" but they had git available,
> > the result is to silently ignore the upstream history and use a
> > tarball import instead.
> >
> > In keeping with the philosophy of making doing the right thing
> > convenient, suboptimals things possible, and requiring mistakes to be
> > explicit, ISTM that the tarball variant should mention that.
>
> "mention that"? Sorry, I'm not sure about how what you say here is a
> response to what I wrote.
I mean, the name for the tarball variant should mention tarball.
> >> An alternative to 'packaging' would be 'debiandir'.
> >
> > In my new taxonomy, I call this "bare debian" so baredebian would be a
> > possibility.
> >
> > I think quilt modes could contain + signs so perhaps
> >baredebian+git
> >baredebian+tarball
>
> This, or debiandir+git and debiandir+tarball, LGTM.
So far I have implemented `baredebian' to mean the with-upstream-git
variant.
I could make baredebian+git an alias for it. Or, rename it. It's not
released yet...
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Hello, On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote: > Are you sure about this conclusion ? Firstly, about "how common": eg, > the current Linux kernel packages have upstream git. Probably best not to assume it's more common, if we can avoid that, indeed. > Secondly: > > If the user says "use upstream from git" but there is no git, the user > gets an error message mentioning git tags and that can also say > something about the other quilt mode. > > If the user says "use upstream tarball" but they had git available, > the result is to silently ignore the upstream history and use a > tarball import instead. > > In keeping with the philosophy of making doing the right thing > convenient, suboptimals things possible, and requiring mistakes to be > explicit, ISTM that the tarball variant should mention that. "mention that"? Sorry, I'm not sure about how what you say here is a response to what I wrote. >> An alternative to 'packaging' would be 'debiandir'. > > In my new taxonomy, I call this "bare debian" so baredebian would be a > possibility. > > I think quilt modes could contain + signs so perhaps >baredebian+git >baredebian+tarball This, or debiandir+git and debiandir+tarball, LGTM. -- Sean Whitton signature.asc Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
maintainer views"):
> On Sun 19 May 2019 at 11:24pm +0100, Ian Jackson wrote:
> > Sean, there is of course the other possibility, where upstream is only
> > a tarball. I propose to intend to support this, eventually, with
> > --quilt=packaging-plus-tar
>
> I think that for workflows where only debian/ is checked into git, not
> having the upstream git history is probably more common than Shengjing's
> case of having an upstream/foo tag.
>
> Thus, I suggest that we use the shorter names --quilt=packaging for the
> tarballs-only case, and --quilt=packaging-git for Shengjing's workflow.
Are you sure about this conclusion ? Firstly, about "how common": eg,
the current Linux kernel packages have upstream git.
Secondly:
If the user says "use upstream from git" but there is no git, the user
gets an error message mentioning git tags and that can also say
something about the other quilt mode.
If the user says "use upstream tarball" but they had git available,
the result is to silently ignore the upstream history and use a
tarball import instead.
In keeping with the philosophy of making doing the right thing
convenient, suboptimals things possible, and requiring mistakes to be
explicit, ISTM that the tarball variant should mention that.
> An alternative to 'packaging' would be 'debiandir'.
In my new taxonomy, I call this "bare debian" so baredebian would be a
possibility.
I think quilt modes could contain + signs so perhaps
baredebian+git
baredebian+tarball
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Hello,
On Sun 19 May 2019 at 11:24pm +0100, Ian Jackson wrote:
> Shengjing Zhu writes ("Bug#903392: want support for packaging-only maintainer
> views"):
>> Here's the example for my package, which only has debian dir in
>> debian-branch.
>>
>> https://salsa.debian.org/zhsj-guest/anbox
>>
> [...]
>
> I observe that in your git repository there is a tag
>upstream/0.0_git20190124
> and that this tag
>(i) appears to contain the upstream git history
>(ii) is absolutely identical to your orig tarball
> anbox_0.0~git20190124.orig.tar.gz
> I think you must have generated the latter with git-deborig or
> something. This is good.
>
>
> I intend to support this with
> --quilt=packaging-git
>
> Sean, there is of course the other possibility, where upstream is only
> a tarball. I propose to intend to support this, eventually, with
> --quilt=packaging-plus-tar
I think that for workflows where only debian/ is checked into git, not
having the upstream git history is probably more common than Shengjing's
case of having an upstream/foo tag.
Thus, I suggest that we use the shorter names --quilt=packaging for the
tarballs-only case, and --quilt=packaging-git for Shengjing's workflow.
An alternative to 'packaging' would be 'debiandir'.
> dgit will look for the corresponding upstream source tag with an
> algorithm like git-deborig's. In case that doesn't work there will
> have to be an option to specify it explicitly.
I think this is right.
The user's first step is to independently select a --quilt option (to
keep typing, or to put in .git/config), which they should always be able
to do, as they know what workflow they intend to use.
Then any additional information dgit can't figure out for itself can be
optional arguments.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Bug#903392: want support for packaging-only maintainer
views"):
> On Sun 19 May 2019 at 11:24PM +01, Ian Jackson wrote:
> > dgit will look for the corresponding upstream source tag with an
> > algorithm like git-deborig's. In case that doesn't work there will
> > have to be an option to specify it explicitly.
>
> I previously modified git-deborig to expose the results of its algorithm
> if you pass --just-print, but there was some further blocker to having
> gdr start using that algorithm instead of reimplementing it.
It occurs to me that dgit has a further strategy available, which
would not be available (nor reasonable) for gdr, nor for git-deborig.
dgit will probably have to construct the tree corresponding to the
.orig in order to detect .orig discrepancies early enough to generate
a reasonable error message. (It has code for this already.)
Having got such a thing, it could hunt through upstream/master or
maybe other branch refs for a commit that has exactly that tree. If
(exactly one?) such a thing is found, it could use it.
dgit could even fetch from Vcs-Git and grobble around in there...
Whether any of this would be useful (or, indeed, sane) depends a lot
on maintainer workflows, about which we seem to know very little. I
definitely think that the right plan is for me to make dgit use the
existing git-deborig tag algorithm and then see if that is enough.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
maintainer views"):
> On Sun 19 May 2019 at 11:24PM +01, Ian Jackson wrote:
> > Sean, there is of course the other possibility, where upstream is only
> > a tarball. I propose to intend to support this, eventually, with
> > --quilt=packaging-plus-tar
>
> "Sean" is a typo? Not sure what my attention is being drawn to, if not :)
I wanted to get your attention on these UI questions :-). In
particular I'm really unsure about these --quilt= style names.
> I previously modified git-deborig [...]
There's another bug about that, I'll reply there...
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
Hello, On Sun 19 May 2019 at 11:24PM +01, Ian Jackson wrote: > Sean, there is of course the other possibility, where upstream is only > a tarball. I propose to intend to support this, eventually, with > --quilt=packaging-plus-tar "Sean" is a typo? Not sure what my attention is being drawn to, if not :) > dgit will look for the corresponding upstream source tag with an > algorithm like git-deborig's. In case that doesn't work there will > have to be an option to specify it explicitly. I previously modified git-deborig to expose the results of its algorithm if you pass --just-print, but there was some further blocker to having gdr start using that algorithm instead of reimplementing it. Let me know if further changes to git-deborig are needed so that we can maintain this algorithm in one place in the archive. -- Sean Whitton signature.asc Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Shengjing Zhu writes ("Bug#903392: want support for packaging-only maintainer
views"):
> Here's the example for my package, which only has debian dir in
> debian-branch.
>
> https://salsa.debian.org/zhsj-guest/anbox
>
> To build, using
>
> gbp clone https://salsa.debian.org/zhsj-guest/anbox
> gbp buildpackage --git-export-dir=../build-area --git-builder=sbuild
>
> I'm not sure if I have magic gbp.conf elsewhere, so let me you if you
> can't build.
Thank you for this and your followup messages. I have now looked at
this. I think it would be very useful to enable dgit push for your
workflow and this is now much higher up on my todo list.
Thank you so much for providing a concrete helpful and clear test/use
case for me. That is invaluable.
For my reference.
I observe that in your git repository there is a tag
upstream/0.0_git20190124
and that this tag
(i) appears to contain the upstream git history
(ii) is absolutely identical to your orig tarball
anbox_0.0~git20190124.orig.tar.gz
I think you must have generated the latter with git-deborig or
something. This is good.
I intend to support this with
--quilt=packaging-git
Sean, there is of course the other possibility, where upstream is only
a tarball. I propose to intend to support this, eventually, with
--quilt=packaging-plus-tar
dgit will look for the corresponding upstream source tag with an
algorithm like git-deborig's. In case that doesn't work there will
have to be an option to specify it explicitly.
Anyone have any comments on these UI decisions ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#903392: want support for packaging-only maintainer views
On Tue, Jul 31, 2018 at 10:50 AM Shengjing Zhu wrote: > > Here's the example for my package, which only has debian dir in > debian-branch. > > https://salsa.debian.org/zhsj-guest/anbox > > To build, using > > gbp clone https://salsa.debian.org/zhsj-guest/anbox > gbp buildpackage --git-export-dir=../build-area --git-builder=sbuild > That should be 1. gbp buildpackage --git-export-dir=../build-area --git-overlay or 2. gbp buildpackage --git-builder=sbuild -- Best regards, Shengjing Zhu
Bug#903392: want support for packaging-only maintainer views
Here's the example for my package, which only has debian dir in debian-branch. https://salsa.debian.org/zhsj-guest/anbox To build, using gbp clone https://salsa.debian.org/zhsj-guest/anbox gbp buildpackage --git-export-dir=../build-area --git-builder=sbuild I'm not sure if I have magic gbp.conf elsewhere, so let me you if you can't build. -- Shengjing Zhu signature.asc Description: PGP signature
Bug#903392: want support for packaging-only maintainer views
Package: dgit Version: 5.7 Severity: wishlist dgit should support packaging-only maintainer views. This is like --quilt=unapplied, except that the upstream files are always directly from the tarball. We will have to fudge the history of the tarball import, somehow. I suggest --quilt=packaging-only ? Speaking to various people on #debian-devel, General practice seems to be to not include .gitignore patches, and often, to build "elsewhere" - even, always to build with sbuild. (There is a problem with some packages whose upstream source is very large. Ideally we would somehow avoid stuffing all that into the maintainer's .git but I can't see how. (Also, all the data ends up being uploaded twice, at least on first upload.) I think this is a problem for the future, and so that is not what this bug is about.) Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
