headers
Marco Mascherpa | 3 Feb 2004 01:23
Picon
Favicon

The Spam issue


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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven Vermeulen | 3 Feb 2004 09:24
Picon
Favicon
Gravatar

Re: The Spam issue

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Vermeulen | 3 Feb 2004 18:07
Picon
Favicon
Gravatar

Re: Status of localisation efforts.

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.org

  http://www.gentoo.org     Documentation & PR              swift <at> gentoo.org
Permalink | Reply | 0 comments |
headers
Sven Vermeulen | 3 Feb 2004 21:35
Picon
Favicon
Gravatar

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

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.org

  http://www.gentoo.org     Documentation & PR              swift <at> gentoo.org
Permalink | Reply | 4 comments |
headers
Tobias Scherbaum | 3 Feb 2004 22:02
Picon
Favicon
Gravatar

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

* 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
Permalink | Reply | 2 comments |
headers
George Shapovalov | 4 Feb 2004 01:33
Picon
Favicon

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

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Roger Miliker | 4 Feb 2004 01:47
Picon
Picon

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

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
George Shapovalov | 4 Feb 2004 03:14
Picon
Favicon

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

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"...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven Vermeulen | 4 Feb 2004 08:45
Picon
Favicon
Gravatar

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

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.org

  http://www.gentoo.org     Documentation & PR              swift <at> gentoo.org
Permalink | Reply | 0 comments |
headers
Lars Weiler | 4 Feb 2004 16:26
Picon
Favicon

English commits and diffs via mail

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
Permalink | Reply | 2 comments |

Gmane