Tales from the Gryphon/ archives/ 2009/

Tales from the Gryphon

Archives for 2009/05

Manoj's hackergotchi
Add a new post titled:
Tuesday 05 May
Link: Debian list spam reporting the Gnus way

Posted early Tuesday morning, May 5th, 2009

Debian list spam reporting the Gnus way

#+TITLE: Debian spam reporting the Gnus way #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ So, recently our email overlords graciously provided means for us minions to help them in their toils and help clean up the spammish clutter in the mailing lists by helping report the spam. And the provided us with a dead simple means of reporting such spam to them. Now, us folks who knoweth that there is but one editor, the true editor, and its, err, proponent is RMS, use Gnus to follow the emacs mailing lists, either directly, or through [[http://www.gmane.org][gmane]]. There are plenty of examples out there showing how to automate reporting spam to /gmane/, so I won't bore y'all with the details. Here I only show how one serves our list overlords, and smite the spam at the same time. Some background, from the Gnus info page. I'll try to keep it brief. There is far more functionality present if you read the documentation, but you can see that for yourself. #+BEGIN_QUOTE The Spam package provides Gnus with a centralized mechanism for detecting and filtering spam. It filters new mail, and processes messages according to whether they are spam or ham. There are two "contact points" between the Spam package and the rest of Gnus: checking new mail for spam, and leaving a group. Checking new mail for spam is done in one of two ways: while splitting incoming mail, or when you enter a group. Identifying spam messages is only half of the Spam package's job. The second half comes into play whenever you exit a group buffer. At this point, the Spam package does several things: it can add the contents of the ham or spam message to the dictionary of the filtering software, and it can report mail to various places using different protocols. #+END_QUOTE All this is very plugin and modular. The advantage is, that you can use various plugin front ends to identify spam and ham, or mark messages as you go through a group, and when you exit the group, spam is reported, ham and spam messages are copied to special destinations for future training of your filter. Since you inspect the marks put into the group buffer as you read the messages, there is a human involved in the processing, but as much as possible can be automated away. /Do/ read the info page on the Spam package in Gnus, it is edifying. Anyway, here is a snippet from my ~etc/emacs/news/gnusrc.el~ file, which can help automate the tedium of reporting spam. This is perhaps more like how Gnus does things than having to press a special key for every spam, and which does nothing to help train your filter. #+BEGIN_HTML [[!syntax language="Common Lisp" linenumbers=1 bars=1 text=""" (add-to-list 'gnus-parameters '("^nnml:\\(debian-.*\\)$" (to-address . "\\1@lists.debian.org") (to-list . "\\1@lists.debian.org") (admin-address . "\\1-request@lists.debian.org") (spam-autodetect . t) (spam-autodetect-methods spam-use-gmane-xref spam-use-hashcash spam-use-BBDB) (spam-process '(spam spam-use-resend)) (spam-report-resend-to . "report-listspam@lists.debian.org") (subscribed . t) (total-expire . t) )) """]] #+END_HTML


Monday 04 May
Link: Reflections on streetcars

Posted terribly early Monday morning, May 4th, 2009

Reflections on streetcars

#+TITLE: Reflections on streetcars #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ Recently, I have made fairly major changes to #+BEGIN_HTML kernel-package, #+END_HTML and there were some reports that I had managed to mess up cross compilation. And, not having a cross-compilation tool chain handy, I had to depend on the kindness of strangers to address that issue. And, given that I am much less personable than Ms Vivien Leigh, this is not something I particularly look forward to repeating. At the onset, building a cross compiling tool chain seems a daunting task. This is not an activity one does frequently, and so one may be pardoned for being non-plussed by this. However, I have done this before, the most recent effort being creating one to compile [[http://www.rockbox.org][rockbox]] binaries, so I had some idea where to start. Of course, since it is usually years between attempts to create cross-compiling tool chains, I generally forget how it is all done, and have to go hunting for details. Thank god for google. Well, I am not the only one in the same pickle, apparently, for there are gobs of articles and HOWTOs out there, including some pretty comprehensive (and intimidating) general tool sets to designed to create cross compilers in the most generic fashion possible. Using them was not really an option, since I would forget how to drive them in a few months, and have a miniature version of the current problem again. Also, you know, I don't feel comfortable using scripts that are too complex for me to understand -- I mean, without understanding, how can there be trust? Also, this time around, I could not decide whether to cross compile for ~arm-elf~, as I did the last time, or for the newfangled ~armel~ target. A need for quickly changing the target for the cross compiler build mechanism would be nice. Manually building the tool chain makes a wrong decision here expensive, and I _hate_ that. I am also getting fed up with having to root around on the internet every time I wanted to build a cross compiler. I came across a script by *Uwe Hermann*, which started me down the path of creating a script, with a help option, to store the instructions, without trying to be /too/ general and thus getting overly complex. However, Uwe's script hard coded too many things like version numbers and upstream source locations, and I know I would rapidly find updating the script irritating. Using Debian source packages would fix both of these issues. I also wanted to use Debian sources as far as I could, to ensure that my cross compiler was as compatible as I could make it, though I did want to use [[http://sources.redhat.com/ml/newlib/][newlib]] (I don't know why, except that I can, and the docs sound cool). And of course the script should have a help option and do proper command line parsing, so that editing the script would be unnecessary. Anyway, all this effort culminated in the following script: #+BEGIN_HTML build cross toolchain, #+END_HTML surprisingly compact. So I am now all set to try and cross compile a kernel the next time a /kernel-package/ bug comes around. I thought that I would share this with the lazy web, while I was at it. Enjoy. The next thing, of course, is to get my script to create a #+BEGIN_HTML qemu #+END_HTML base image every week so I can move from user mode Linux to the much more nifty #+BEGIN_HTML kvm, #+END_HTML which is what all the cool kids use. And then I can even create an /arm/ virtual machine to test my kernels with, something that user mode linux can't easily do.


Webmaster <webmaster@golden-gryphon.com>
Last commit: terribly early Sunday morning, June 8th, 2014
Last edited terribly early Sunday morning, June 8th, 2014