The Spam issue

Marco Mascherpa <m.mascherpa <at> gentoo.org>
2004-02-03 00:23:22 GMT

Lately I have a big problem with spam: my inbox gets everyday filled with
almost a hundred spam messages, and they are beginning to represent an
interesting percentage of my whole mail traffic.
SpamAssassin is working all the time, it learns, it scans, it checks with
every online database available, but in the last few weeks too many spam
messages got out of is control.
Most of the spam messages come from the email published in the Docs i worked
for and Google says there's no other place where it could be retrieved other
than Gentoo website and links to it.
My request is very simple: could it be possible to protect developers email
addresses? Could it be possible to create some XSL stylesheet that
automagically converts "my <at> email.com" to my [AT] email [DOT] com" or similar
solutions? Could it be possible to run this script on ALL the documents,
including old ones?
I'm not just illuding myself that such a solution will provide some quiet
period to my POP3 server and my KMail client, but i just have to feel that
i'm doing something agaist it, i can't stand those dozens of rubbish mail any
more!
Has anyone got better ideas?
--
--
Marco Mascherpa
GPG public key: http://mush.monrif.net/mush.asc

Re: The Spam issue

Sven Vermeulen <swift <at> gentoo.org>
2004-02-03 08:24:46 GMT

On Tue, Feb 03, 2004 at 01:23:22AM +0100, Marco Mascherpa wrote:
> My request is very simple: could it be possible to protect developers email
> addresses? Could it be possible to create some XSL stylesheet that
> automagically converts "my <at> email.com" to my [AT] email [DOT] com" or similar
> solutions? Could it be possible to run this script on ALL the documents,
> including old ones?
You cannot know for sure that the spamlist took your e-mail address from the
documentation. It only needs to be listed once somewhere (for instance in a
signature, on a mailinglist, in a newsgroup - but of course also on our
documentation, GWN or other material) to be taken up by some spam bot.
Of course having the e-mail address publicised on the documentation makes it
easy for spambots, but I don't see why we would make it more difficult for
the user to get in touch with us, especially knowing that only a single
spambot must pick up our e-mail address and distribute it to others, while
users will individually try and reach us - they don't distribute e-mail
addresses.
Now, for your question on the XSLT rewrite: It is possible; some rewriting on
the text() of the link-attribute in the mail entity. It will however affect
the whole Gentoo website, which may not be what we want to do. We can of
course go check if a document is a guide rather than part of the Gentoo
website itself, but things like this clutter up the whole XSLT more and more
- it's already quite ugly.
> Has anyone got better ideas?
More "harsh" anti-spam filters? Mine moves all HTML e-mails in a separate
mailbox which I read about twice a week. Too bad for the people that want a

Re: Status of localisation efforts.

Sven Vermeulen <swift <at> gentoo.org>
2004-02-03 17:07:48 GMT

On Thu, Jan 22, 2004 at 01:41:07PM +0100, Sven Vermeulen wrote:
> Since the $lang.g.o project has maintainers (quite possibly the translation
> team/leads of the language) I don't think it is too difficult for them to
> translate the index.xml file. It may even lead to more supported languages...
Hrm, changed my mind here. I think that we shouldn't support localised
versions of gentoo.org if the language isn't actively supported by the
documentation team. What use does a localised gentoo.org have if none of the
documentation is available for that language anyway?
Wkr,
Sven Vermeulen
--
--
FOSDEM 2004 Free and Open Source Developers European Meeting
21 - 22 februari Brussels, Belgium http://www.fosdem.orghttp://www.gentoo.org Documentation & PR swift <at> gentoo.org

Removal of "emerge /path/to/ebuild" instruction from handbook

Sven Vermeulen <swift <at> gentoo.org>
2004-02-03 20:35:37 GMT

Hi all,
I've removed the "emerge /path/to/ebuild" paragraph from
hb-working-portage.xml as the right way to deal with masked ebuilds is to use
/etc/portage/package.umask (which was already described above that
paragraph).
It's currently still listed in portage-manual.xml though. I'll remove it from
that one too if I feel up to it, otherwise I'll leave it there until it is
rewritten.
Wkr,
Sven Vermeulen
--
--
FOSDEM 2004 Free and Open Source Developers European Meeting
21 - 22 februari Brussels, Belgium http://www.fosdem.orghttp://www.gentoo.org Documentation & PR swift <at> gentoo.org

Re: Handbook fits on a single page w/ inserted texts in right language

Tobias Scherbaum <dertobi123 <at> gentoo.org>
2004-02-03 21:02:54 GMT

* Tobias Scherbaum <dertobi123 <at> gentoo.org> [2004-01-23 11:28]:
> * Xavier Neys <neysx <at> gentoo.org> [2004-01-23 00:53]:
> > Could someone (SwifT?) with an axkit setup do some tests as well?
> > It can't go live before it is properly tested.
>
> I can do some tests, just give me a few days too ...
I can't get it working, if you want I can send you some snippets from
the error_log. :(
Maybe someone with a bit more time has more luck ...
Regards,
Tobias

Re: Removal of "emerge /path/to/ebuild" instruction from handbook

George Shapovalov <george <at> gentoo.org>
2004-02-04 00:33:43 GMT

Hi Sven.
Why remove it from the manula at all? After all this is a supported
functionality that has valid uses (say you want to emerge something once for
testing and do not care or do not want possible upgrades, and yea, it is fine
if it gets removed during the next update...).
IMHO it is better to just add a note that such way of installing things has
its drawbacks...
George
On Tuesday 03 February 2004 12:35, Sven Vermeulen wrote:
> Hi all,
>
> I've removed the "emerge /path/to/ebuild" paragraph from
> hb-working-portage.xml as the right way to deal with masked ebuilds is to
> use /etc/portage/package.umask (which was already described above that
> paragraph).
>
> It's currently still listed in portage-manual.xml though. I'll remove it
> from that one too if I feel up to it, otherwise I'll leave it there until
> it is rewritten.
>
> Wkr,
> Sven Vermeulen
--
gentoo-doc <at> gentoo.org mailing list

Re: Removal of "emerge /path/to/ebuild" instruction from handbook

Roger Miliker <roger_miliker <at> gmx.at>
2004-02-04 00:47:33 GMT

On Wednesday 04 February 2004 01:33, George Shapovalov wrote:
> Hi Sven.
>
> Why remove it from the manula at all? After all this is a supported
> functionality that has valid uses (say you want to emerge something once
> for testing and do not care or do not want possible upgrades, and yea, it
> is fine if it gets removed during the next update...).
> IMHO it is better to just add a note that such way of installing things has
> its drawbacks...
>
it's far easier to leave that to people who *know* their packagemanager.
Let's say I want to try out kde-3.2 (masked and keyworded) :
emerge -p /usr/portage/kde-base/kde/kde-3.2.0_rc1.ebuild
These are the packages that I would merge, in order:
Calculating dependencies \
!!! all ebuilds that could satisfy "~kde-base/kdeaddons-3.2.0_rc1" have been
masked.
!!! (dependency required by "kde-base/kde-3.2.0_rc1" [ebuild])
!!! Error calculating dependencies. Please correct.
Now what?
That happens if a ~x86 ebuild has an ~x86 dep too.
Same goes for masked ebuilds.

Re: Removal of "emerge /path/to/ebuild" instruction from handbook

George Shapovalov <george <at> gentoo.org>
2004-02-04 02:14:50 GMT

Sorry, I was too brief last time.
On Tuesday 03 February 2004 16:47, Roger Miliker wrote:
> On Wednesday 04 February 2004 01:33, George Shapovalov wrote:
>
> Let's say I want to try out kde-3.2 (masked and keyworded) :
>
> emerge -p /usr/portage/kde-base/kde/kde-3.2.0_rc1.ebuild
[skipped]
>
> So besides your "drawbacks" it doesn't work too.
Actually it does, - if you noticed it complains not about kde itself but about
its first (masked in this case) dependency. Definitely this function requires
a better description and person tunning it actually understanding what's
going on. I totally agree that its mention should be removed from the generic
introductory doc, but the manual is supposed to be a comprehensive reference
for the tool. If we remove it everywhere (including the manual), where a
persom who has no prior knowledge is going to learn about this?
The last one was also geared towards this point ;).
> it's far easier to leave that to people who *know* their packagemanager.
I think it would be better to (while removing the mention of this way form
other sources still keep it in the manual and) just add a note discussing
possible implications. Something alogn the lines "beware that the package you
are trying to emerge might be masked due to the problems with its
dependencies, in which case you might get an emerge failure reporting that
certain dependency cannot be satisfied"...

Re: Removal of "emerge /path/to/ebuild" instruction from handbook

Sven Vermeulen <swift <at> gentoo.org>
2004-02-04 07:45:54 GMT

On Tue, Feb 03, 2004 at 06:14:50PM -0800, George Shapovalov wrote:
> > it's far easier to leave that to people who *know* their packagemanager.
>
> I think it would be better to (while removing the mention of this way form
> other sources still keep it in the manual and) just add a note discussing
> possible implications.
I agree that it shouldn't become an undocumented feature, but it shouldn't be
listed in the second part of the Gentoo Handbook. That part is created for
users who want to learn Gentoo and want to know how to deal with Portage.
Perhaps the Portage Manual is the right place to have it in, perhaps the
upcoming "Gentoo Development" part is the right place, perhaps none of them
are.
Wkr,
Sven Vermeulen
--
--
FOSDEM 2004 Free and Open Source Developers European Meeting
21 - 22 februari Brussels, Belgium http://www.fosdem.orghttp://www.gentoo.org Documentation & PR swift <at> gentoo.org

English commits and diffs via mail

Lars Weiler <pylon <at> gentoo.org>
2004-02-04 15:26:28 GMT

Hi all,
I would like to announce a new mailing-list for the commits
on htdocs/en. The messages will also show the changes in
the file. This could be very interesting for translators,
so they get informed about changes to the English docs.
If you want to receive these mails, send a clear message to
gentoo-doc-cvs-subscribe <at> gentoo.org
Furthemore I did some changes to viewcvs so that there is
now the new Project Root "doc" which opens directly
gentoo/xml/htdocs. Also Attic-files are now shown directly
instead of a separate directory.
Regards, Lars