Since Diego is deleting my comments from his moderation queue, I'll try to give my impression of his post here. But first I'll state my opinion on the matter.

I think the Council made a mistake (admittedly, not a big one) by missing their latest meeting. And I don't particularly care about why it happened. Also, I don't think they have to give either reasons or excuses, this kind of stuff might happen, and that's all.

However, there's one reason the Council exists: because we all voted for what today is GLEP39 (which wasn't a GLEP by that time, as far as I recall). And said document states it clearly:

If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.

There is no point in enforcing such a rule when Council members are late even for half an hour (or even a couple of hours). But there is no enforcing here, you guys missed the meeting, rules say you have to call an election. Hell, those of you who got my vote will get it again. (And I'm quite sure that's the situation for lots of people).

Just follow the rules that give you the power you have.

However, I find it interesting that Diego, who is a Council member, didn't read the summary of that meeting:

As per http://archives.gentoo.org/gentoo-dev/msg_19892c04f0e6cf4c24629f13718e45cb.xml there was a meeting council scheduled for 20:00 UTC today (that's a bit more than half an hour ago).

For some reason, only amne and dberkholz showed up. As per GLEP39's Specification:

• If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.

What's the council going to do? Place your bets.

— ferdy

A serious security issue in paludis was brought to my attention recently, and I feel I should make you all aware. Apparently someone, with root access to a machine, can gain root access by installing or editing paludis config files.

For those interested, this is how it happened (times are GMT+1):

22:34 <@ferdy> bonsaikitten: can you give me any details regarding that
 security bug in paludis?
22:35 <+bonsaikitten> ferdy: it's so obvious you should have found it already
22:37 <@ferdy> bonsaikitten: I should, but I probably haven't
22:37 <+bonsaikitten> ferdy: well, as I am a moron I'm unable to coherently explain :)
22:37 <@ferdy> bonsaikitten: I mean, depends on whether we are talking about
a real security issue or about something we should document to avoid people
shooting themselves in the foot
22:39 <@ferdy> bonsaikitten: is that all you are going to tell me?
22:39 <+bonsaikitten> ferdy: come on, it's obvious. You're supposed to be smart ...
22:39 * bonsaikitten is not in a mood to explain
22:40 <@ferdy> bonsaikitten: you aren't really talking about the paludisbuild issue, are you?
22:41 <+bonsaikitten> mmh no, that's a different one
22:41 <@ferdy> k
22:41 <@ferdy> bonsaikitten: what are we talking about?
22:42 <@ferdy> bonsaikitten: you don't need to explain it... just say, in general 
terms, what the issue is
22:50 <@ferdy> bonsaikitten: so? care to give any useful hint?
22:50 <+bonsaikitten> ferdy: doesn't happen in portage compatibility mode
22:51 <+bonsaikitten> but I blame the vodka, hard to explain when *burp* *giggle*
22:52 <@ferdy> bonsaikitten: what's the impact?
22:53 <+bonsaikitten> ferdy: depends on how annoying the other person is
22:54 <+bonsaikitten> ferdy: worst case random file modification
22:58 <@ferdy> bonsaikitten: and we already agreed that we aren't talking about
the paludisbuild issue, right?
22:59 <@ferdy> bonsaikitten: if we aren't, I'll need more hints....
23:05 <@ferdy> bonsaikitten: can I get an attack vector?
23:05 <@ferdy> that shouldn't need lots of explaining... I can figure out that
part myself
23:19 <@ferdy> bonsaikitten: have you got that attack vector for me?
23:24 <+bonsaikitten> ferdy: look at configuration files, maybe you notice that
there's some exquisit code execution possible there
23:29 <@ferdy> bonsaikitten: you mean those config files that only root can
edit? I must be missing something here
23:29 <+bonsaikitten> ferdy: you are :)
23:29 <+bonsaikitten> not much, and it's basically the same flaw bashrc is
for portage
23:29 <+bonsaikitten> only that bashrc is config_protect'ed ...
23:30 <@ferdy> bonsaikitten: but for a package to clover those files, it must be
in a repo root added, right?
23:31 <+bonsaikitten> someone in the package mangler group, but yes
23:35 <@ferdy> bonsaikitten: but if you can change those files in the first place,
why clover them by adding a malicious repo with a malicious package that changes
those files?
23:35 <+bonsaikitten> ferdy: because it's very subtle
23:36 <@ferdy> moreover, if you can already do that, why not just make the
package install whatever backdoor you want?
23:37 <@ferdy> I mean, it is subtle, but why would anyone go the 'convoluted'
route? he is already able to edit those files (since he had to add that repo)
23:38 <+bonsaikitten> 'cause only paludis is affected and you will find it very
hard to trace
23:38 <+bonsaikitten> that makes it so tempting ...
23:40 <+bonsaikitten> just don't be surprised if it suddenly unmerges itself :)
23:41 <@ferdy> yeah... well...
23:41 <@ferdy> bonsaikitten: mind if I disclose this vulnerability in
 planet.gentoo.org?
23:42 <+bonsaikitten> go ahead
23:42 <@ferdy> ta
23:42 <+bonsaikitten> 't is even on the features page of the package mangler :)

This is a good lesson to learn today:

If you can edit files owned by root in a machine, you can get root access to that machine.

So the bottom line is: There is no vulnerability, if you can mangle paludis config files, you are already root so you don't need to edit a file to run any command you want. Another lesson one can learn by reading that log is how to be really cooperative.

Ah, and before someone with a need to use cheap psychology asks, the intention of this blag post is to stop the FUD.

- ferdy

...you get up, fire your mail client just to find:

https://bugs.gentoo.org/show_bug.cgi?id=64840
https://bugs.gentoo.org/show_bug.cgi?id=168573
https://bugs.gentoo.org/show_bug.cgi?id=161368

Please take the time to read those 'Excerpts', they are really enlightening. Politics is so much fun.

Some facts:

• All of them work in Paludis
• Some of them have been vocal against how #gentoo and forums.gentoo.org are managed and its politics.
• Using the image I posted yesterday as an avatar is one of the reasons one of them got the boot.

I wonder who is going to be next. I also wonder who 'started' the process. It is difficult to know, because the bug is restricted ( https://bugs.gentoo.org/show_bug.cgi?id=216219 ).

Way to go Gentoo. No love for you today.

- ferdy

I hear this image got someone a Developer Relations complain. Way to go, Gentoo. Way to go.

You are clearly doing it wrong.

(For those that aren't aware of this rather old issue: have fun).

- ferdy

I'm proxy-posting this to Gentoo Planet from yoswink:

---

During the last week, the people of Isla Cristina (a beautiful town in the Atlantic coast with probably the best beaches of all Spain) organized an event called '1st Technological days of Isla Cristina'. They invited me to participate and give a talk about Gentoo.

On Friday I was there explaining what makes our distribution different, what the 'All about choice' is and the technology behind it. I shared the day with Spanish developers of other open source projects such as OpenBSD, NetBSD and KDE.

The day organization was perfect, any more to say, it couldn't be better. I want to thanks the people (teachers and students) from IES Mirabent, who fought to make this idea a reality in a small town of 22k people (is not so common to find this kind of event in Spain with official devs from big OSS projects even in the big cities or universities), and to the youth department of Isla Cristina for all they have done for me.

If someone want to take an example about how an event should treat a lecturer, please contact with them.

P.D: thanks to Julio Merio from NetBSD for lending me the computer (I forgot the damn Mini-DVI cable) and sorry to Antonio Larrosa from KDE, I ate some minutes of his time :(

---

Apparently, people are bashing Joshua Jackson (a.k.a. tsunam) for posting his opinion (which happens to be shared among lots of us). So just in case someone hasn't read what he said yet, I'm going to link his posts here. Please, do read them:

http://tsunam.org/2008/01/12/in-response/
http://tsunam.org/2008/01/14/clarifications/
http://tsunam.org/2008/01/14/tool-box/

I simply can't trust Daniel Robbins after what he tried to do the last time he tried to come back. Has everybody forgotten that? I hope not.

No love.

- ferdy

Once we've converted native types we face the task of converting arbitrary classes and types. Another thing we'll need is extract the C++ type of a Java object (jobject in JNI).

For that task, we will follow the convention of calling the native pointers in Java classes _ptr. With that, we can define the following templates:

template <typename T_>
inline T_ * get_native_ptr(JNIEnv * env, const char * const class_name, jobject obj)
{
    jclass cls(env->FindClass(class_name));
    jfieldID ptr_field(env->GetFieldID(cls, "_ptr", "J"));
    jlong ptr(env->GetLongField(obj, ptr_field));
    env->DeleteLocalRef(cls);
    return from_java_ptr<T_>(ptr);
}

template <typename T_>
inline tr1::shared_ptr<T_> get_native_sptr(JNIEnv * env, const char * const class_name, jobject obj)
{
    jclass cls(env->FindClass(class_name));
    jfieldID ptr_field(env->GetFieldID(cls, "_ptr", "J"));
    jlong ptr(env->GetLongField(obj, ptr_field));
    env->DeleteLocalRef(cls);
    return from_java_ptr_sptr<T_>(ptr);
}

This should really be doing more error checking, but it is good enough for ilustrating how nice are things when using proper tools (both languages and libraries).

Converting arbitrary types also uses some template magic:

template <typename T_>
struct NativeToJavaTypeMapper
{
    jobject operator() (JNIEnv *, const T_ &);
};

Now we need specializations for each type we want to convert, for instance, converting a paludis' FSEntry into a java.io.File looks like the following:

template<>
struct NativeToJavaTypeMapper<FSEntry>
{
    jobject operator() (JNIEnv * env, const FSEntry & f)
    {
        jclass cls(env->FindClass("java/io/File"));
        jmethodID constructor(env->GetMethodID(cls, "<init>", "(Ljava/lang/String;)V"));
        jobject ret(env->NewObject(cls, constructor, to_java_string(env, stringify(f))));
        env->DeleteLocalRef(cls);
        return ret;
    }
};

Neat and clean.

For containers, a java.util.LinkedList would be used for paludis' Sequence; and java.util.TreeSet for paludis' Set:

template <typename T_, typename It_>
jobject range_to_list(JNIEnv * env, It_ begin, It_ end)
{
    jclass list_class(env->FindClass("java/util/LinkedList"));
    jmethodID constructor(env->GetMethodID(list_class, "<init>", "()V"));
    jobject our_list(env->NewObject(list_class, constructor));
    jmethodID add_method(env->GetMethodID(list_class, "add", "(Ljava/lang/Object;)Z"));

    for (It_ i(begin) ; i != end ; ++i)
        env->CallBooleanMethod(our_list, add_method, NativeToJavaTypeMapper<T_>()(env, *i));

    env->DeleteLocalRef(list_class);

    return our_list;
}

template <typename T_, typename It_>
jobject range_to_set(JNIEnv * env, It_ begin, It_ end)
{
    jclass set_class(env->FindClass("java/util/TreeSet"));
    jmethodID constructor(env->GetMethodID(set_class, "<init>", "()V"));
    jobject our_set(env->NewObject(set_class, constructor));
    jmethodID add_method(env->GetMethodID(set_class, "add", "(Ljava/lang/Object;)Z"));

    for (It_ i(begin) ; i != end ; ++i)
        env->CallBooleanMethod(our_set, add_method, NativeToJavaTypeMapper<T_>()(env, *i));

    env->DeleteLocalRef(set_class);

    return our_set;
}

And now defining NativeToJavaTypeMapper specializations for containers is quite easy:

template<>
template <typename T_>
struct NativeToJavaTypeMapper<tr1::shared_ptr<const Sequence<T_> > >
{
    jobject operator() (JNIEnv * env, const tr1::shared_ptr<const Sequence<T_> > & s)
    {
        return range_to_list<T_>(env, s->begin(), s->end());
    }
};

template<>
template <typename T_>
struct NativeToJavaTypeMapper<tr1::shared_ptr<const Set<T_> > >
{
    jobject operator() (JNIEnv * env, const tr1::shared_ptr<const Set<T_> > & s)
    {
        return range_to_set<T_>(env, s->begin(), s->end());
    }
};

I've spent a fair amount of the time fighting with make and the build system. It looks mostly sane now, though.

Dealing with exceptions has been a bit tricky, however, I think I have a good system to deal with it now, even though Ciaran tagged it as icky and ugly . That'd be the topic of the next part of the series.

The documentation is currently at http://dev.gentoo.org/~ferdy/paludis-jni/ . All of that has been accomplished in:

[ $ ~/git/paludis/jni(jni) ] git diff --shortstat trunk..
 65 files changed, 4371 insertions(+), 0 deletions(-)

Which is not a lot of code for what's exposed.

— ferdy

After showing how is the structure of a regular Paludis class using JNI, next thing is showing part of the magic behind paludis_java.hh.

What's there is functions to convert Java types into Paludis (and C++ native) types and viceversa (this conversions exist only when needed, not for every single type). So, for instance, one of those conversions would be jboolean <--> bool and it looks like this:

inline jboolean to_java_boolean(bool b)
{
    return b ? JNI_TRUE : JNI_FALSE;
}

inline bool from_java_boolean(jboolean b)
{
    return b == JNI_TRUE;
}

That was easy, let me show you the dirty part. I call it dirty not because it is difficult or tricky to understand, but because it is a bit icky. It is the way we store the native Paludis pointers in Java classes:

inline jlong to_java_ptr(void * const ptr)
{
    return reinterpret_cast<jlong>(ptr);
}

template <typename T_>
inline T_ * from_java_ptr(jlong ptr)
{
    return reinterpret_cast<_ *>(ptr);
}

template <typename T_>
inline tr1::shared_ptr<T_> from_java_ptr_sptr(jlong ptr)
{
    return * reinterpret_cast<tr1::shared_ptr<T_> *>(ptr);
}

Although dirty, it is quite easy aswell. Something this bindings will be converting a lot is strings:

std::string
from_java_string(JNIEnv * const env, jstring s)
{
    const char * const c_s(env->GetStringUTFChars(s, 0));
    std::string result(c_s);
    env->ReleaseStringUTFChars(s, c_s);
    return result;
}

jstring
to_java_string(JNIEnv * const env, const std::string & s)
{
    return env->NewStringUTF(s.c_str());
}

And since C++ is such a nice language comparing and stringifying arbitrary types was just as easy (credits for this go to Mr. McCreesh):

template <typename T_>
jstring common_stringify(JNIEnv * const env, jlong ptr)
{
    return to_java_string(env, stringify(*from_java_ptr<T_>(ptr)));
}

template <typename T_>
jint common_compare(jlong lhs_ptr, jlong rhs_ptr)
{
    T_ * const lhs(from_java_ptr<T_>(lhs_ptr)), * const rhs(from_java_ptr<T_>(rhs_ptr));
    if (*lhs < *rhs)
        return -1;
    else if (*rhs < *lhs)
        return 1;
    else
        return 0;
}

This wasn't quite difficult and it certainly makes working with JNI easier. However, there is still stuff to do (actually, to show, since it is implemented and working in my git repository) like exception handling, converting arbitrary Paludis types and typesafe containers.

During the weekend I've written bindings for almost every core Paludis class and the patch is not that big:

[ $ ~/git/paludis(jni) ] git diff --shortstat trunk..
 30 files changed, 1975 insertions(+), 0 deletions(-)

Now it is time to stop the bindings for a while and start writing documentation, examples and integrating the bindings into the Paludis codebase properly.

Next part of the series will be about how I am converting arbitrary types and containers into Java types and typesafe collections respectively.

— ferdy

Some days ago, the Wearer of the shiny hat started tinkering with JNI bindings for Paludis.

Even if we all think Java is perverse and should be avoided at all costs. Having used Java for the last four years and having studied part of the Java5 code I thought I could use everything I learnt and took the task of developing and maintaining the JNI bindings.

It has all been relatively easy. It's good that Ciaran started them; because his experience with the Ruby bindings gave the key to developing the Java bindings cleanly.

What we are currently doing is storing a C++ pointer in Java classes and passing it around in native methods. Then we delete it when Java's garbage collector decides it is good to call finalize.

So it mostly looks like this:

package paludis;
import paludis.Paludis;

public class Foo {
    private static Paludis _load_the_frickin_paludis_library = new Paludis();
    private long _ptr;

    private static native long _construct_string(String s);
    private static native void _destruct(long ptr);

    private static native boolean _is_foo(long ptr);

    protected void finalize() throws Throwable {
        _destruct(_ptr);
        super.finalize();
    }

    public Foo(String s) {
        _ptr = _construct_string(s);
    }

    public boolean isFoo() {
        return _is_foo(_ptr);
    }
}

Then the C++ part looks like this:

/* vim: set sw=4 sts=4 et foldmethod=syntax : */

#include "foo.hh"
#include "paludis_java.hh"
#include <jni.h>
#include <paludis/foo.hh>

using namespace paludis;
using namespace paludis::java;

JNIEXPORT jlong JNICALL
Java_paludis_Foo__1construct_1string(JNIEnv * env, jclass, jstring s)
{
    return to_java_ptr(new Foo(from_java_string(env, s)));
}

JNIEXPORT void JNICALL
Java_paludis_Foo__1destruct(JNIEnv *, jclass, jlong ptr)
{
    delete from_java_ptr<Foo>(ptr);
}

JNIEXPORT jboolean JNICALL
Java_paludis_Foo__1is_1foo(JNIEnv *, jclass, jlong ptr)
{
    return to_java_boolean(from_java_ptr<Foo>(ptr)->is_foo());
}

Here, all the magic is happening behind the scenes in the paludis_java.hh header which I'll show in a future post of the Paludis meets Java series.

— ferdy

It is often surprising how some people can really lose control of a situation.

Take this example http://dev.gentoo.org/~ferdy/tmp/seemant-moron.log . It is actually sad having to deal with that kind of thing. I asked three times for an apology and (surprise surprise) I didn't get one. One publicly in IRC, another one in a /query and a third one by mail.

Besides wondering who is the one acting like a moron, I really wonder why people have the feeling that Gentoo is oh so nice and friendly.

No love.

— ferdy

PS: Despite of his attitude, I still can't be bothered with personal issues. So if he wanted me to have an issue with him, I'm thankful he failed.

So Greg KH wonders how to fix his macro in mutt.

Here you have something that works. Doesn't do anything fancy (in fact it is useless), but I guess you could adapt it to suit your needs:

macro index T "<enter-command>unset wait_key\n \
                <pipe-message>cat - > /home/ferdy/foo.blah\n \
                <shell-escape>vim -c 'set ft=mail' /home/ferdy/foo.blah\n \
                <enter-command>set wait_key\n"

I tried using 'decode-save' and/or 'save-message' but for some reason it didn't work. I guess you could replace 'x.sh' or almost all of it with a mutt macro like the one above.

Cheers,
Ferdy

There is a traditional puzzle where 3 missionaries and 3 cannibals have to cross a river using a small canoe. Rules are:

* You cannot have more cannibals than missionaries in either bank because cannibals will eat missionaries.
* The canoe can be run by either one or two persons. Both cannibals and missionaries know how to run it.

This puzzle is really easy to solve either by hand or programming. However, hacking a script to solve it is always more challenging than solving it by hand. Juanjo proposes a solution using Ruby in Misioneros y can

So It's been a long time since I wrote anything, not because I've done much for Gentoo but because Uni starts sucking once again.

However I found some time to do a couple of (maybe) interesting things:

I added some base-system binary packages for alpha. So if you screwed your alpha instalation doing something brave (or stupid) just take a look at http://dev.gentoo.org/~ferdy/bins/alpha/. You should be able to recover your system if you have a working busybox (which you SHOULD have).

I also managed to build 'The Glorious Glasgow Haskell Compiler' under alpha. Even if it is an unregisterised build, the result binaries are pretty usable (although they are HUGE). I built darcs with it and works perfectly. If you want to give it a try, get it from the url above, and put it in /usr/portage/packages/. You should be able to 'emerge -k' it by just removing the <virtual/ghc-6.5 dependency in dev-lang/ghc-6.4.1-r1.

I'll work with the gentoo-haskell guys to get it into the portage tree soon. Since I'm learning haskell, expect more haskell-related alpha porting :)

I also hacked a portage atom parser in haskell for a script I've been meaning to do for a long time. Doesn't do anything fancy yet since I'm still implementing the Ord class operators. However it is considerably fast, it parses ~71000 lines in less than 1.5 seconds. Get AtomParser.hs and see a proof of concept showing its use in parser-test.hs. ( I'm still learning haskell so yes, it is really easy to improve my code ).

Since ctags is almost unmaintained upstream I've been collecting some useful patches around the net and might consider give it a big bump in the near future. The patches series are (in order):

• Haskell support [by me]
• Very basic ObjC support (ObjC hackers are welcome to send me ideas and code to improve the regexes) [by me]
• Add patch to make Ruby class names in the form Foo::Bar work [by Ciaran McCreesh]
• Add patch to improve C handling [by vim hackers, pointed out by Ciaran McCreesh]
• Add support for Java 5 generics [found somewhere in the ctags forums]
• Ebuild syntax support [by Ciaran McCreesh]

If you have an interesting and useful patch for ctags, please send it my way so I can integrate it in the next bump if I ever manage to do it. I'm maintaining all those patches in a stgit repository that I might share if anybody asks me to do it.

Also the Alpha Arch Testers project is reaching its final stage. We've got a quiz and we are giving the final touches to a policy document describing how we should behave (i.e. herd and arch-testers) one to each other.

Also I'm looking forward to Stephen Bennett's SELinux work under alpha. He kind of promised to test the hardened-sources; it'll rock if he gets them work; because since the grsec-sources were removed we've got no 'secure' sources in the tree.

And last (and probably least) I wrote a dirty bash script some time ago and thought I might share. It simply lists the files that are no longer 'claimed' by any package installed under /usr/portage/distfiles. I know there are some nice python scripts around but I found this one to be way faster than those. WARNING: It is a hack, it won't work without gnu-sed and will probably miss some files. However, it seems to work great here. If you want to give it a try, it is here (distfiles-clean). ( More scripts in http://gentoo-es.org/~ferdy/git/?p=gentoo-scripts.git;a=summary )

Ok time to get back to the mips assembly University work...

Cheers,
Ferdy

I've been working on dev-util/git and git-related software for a week and today I committed the following git related packages and enhancements:

dev-util/git - An init script to use git-daemon. It is way faster than HTTP for 'clone' and 'fetch' (and thus 'pull'). A really nice way to share repositories if you don't have lots of bandwidth.

dev-util/stgit - Stacked GIT is a SCM on top of GIT that works a la quilt. Lets you manage a series of patches in a stack fashion.

www-apps/gitweb - Gitweb is a handy cgi script to show git repositories 'via Web'. It uses webapp.eclass. I've added this one to package.mask because I think it needs a bit more testing before going to ~arch. Unmask it, test it, and send feedback please :)

I started using git a month ago and I've migrated almost all my code to git. The documentation is good enough and git's layout is in fact very easy. Moreover, there are scripts to import both cvs and arch repositories (git-cvsimport and git-archimport). Both of them work pretty good as far as I know.

Test and enjoy them ;-)

Yesterday I added a new mutt version to the tree (1.5.11, ~arch). Except from a bug regarding SASL that I fixed a couple of hours after adding it; should work fine.

I also added maildrop-2.0.0 to the tree AND package.mask. This version comes with nice features such as fam integration and uses libpcre for pattern matching. Please test it and send bugs if you find any. I'm using it without problems so it shouldn't break too badly :)

A simple:

# echo '>=mail-filter/maildrop-2.0.0' >> /etc/portage/package.unmask
# emerge -va maildrop

should do it.

Cheers,
Ferdy

I also voted for the council2005 election as Grant did. It is really important that every developer takes at least 5 minutes to vote. So either vote or don't complain if you don't like the council (or its decissions) when the election closes !

Have you voted? If not, what are you waiting for ?

Cheers,
Ferdy

Hi !

All of you suffering from a 'virus attack' on your g.o accounts and not using an insane mail filtering engine might like this.

in .mailfilter:

exception {
        xfilter "/usr/bin/spamc"
        xfilter "/usr/bin/clamassassin"
}

if ( /^X-Spam-Status: .*Yes,/ )
{
        to ".maildir/.spam"
}

if ( /^X-Virus-Status: .*Yes/ )
{
        to "/dev/null"
}

in .forward:

|/usr/bin/maildrop -d ferdy

Thanks infra for letting us use clamassassin... I desperately needed it. Now my INBOX is much cleaner.

Cheers,
Ferdy

As slarti announced a few days ago, mailer-config is on its way to ~arch.

We have commited several packages using the new scheme. This is a package.mask excerpt:

# mask these until the new mailwrapper/mailer-config scheme is ready
# it is secure to unmask them to test
net-mail/mailer-config
=net-mail/mailwrapper-0.2.1-r1
=mail-mta/nbsmtp-0.98-r1
=mail-mta/msmtp-1.4.0-r1
=mail-mta/ssmtp-2.61-r1
=mail-mta/esmtp-0.5.0-r2

It is safe to unmask them to start testing. The *big* mailers to come soon; I'm currently working on postfix and I'll probably have it by tonight or tomorrow.

A few 'shots' to show it working:

posidon root # mailer-config -l
[1] default *
[2] esmtp-0.5.0
[3] nbsmtp-0.98
[4] ssmtp-2.61
posidon root # mailer-config -s 2
 * New default profile is: esmtp-0.5.0
posidon root # mailq
Mail queue is empty
posidon root # mailer-config -s 3
 * New default profile is: nbsmtp-0.98
posidon root # mailq
Showing queued mails in /root/.nbsmtp/.queue:

posidon root # mailer-config -s 4
 * New default profile is: ssmtp-2.61
posidon root # mailq
mailq: Mail queue is empty
posidon root # mailer-config -s 3
 * New default profile is: nbsmtp-0.98
posidon root # mailer-config -l  
[1] default
[2] esmtp-0.5.0
[3] nbsmtp-0.98 *
[4] ssmtp-2.61
posidon root # 

As you can see, three completely different behaviors of mailq, each one depending on which mailer profile you are using. This is great stuff ! We would like to hear your opinion about it.

Cheers,
Ferdy

Hi all !

New mailbase version (net-mail/mailbase-0.00-r9 ~arch) will not change your /var/spool/mail/ permissions anymore.

Anyway since some net-mail devs think that the only right permissions in /var/spool/mail/ are 0775. If you set something different, mailbase will not overwrite them, but it will show you a nice warning:

  * Your /var/spool/mail/ directory permissions differ from
  *  those which mailbase set when you first installed it (0775).
  *  If you did not change them on purpose, consider running:
  *
       chmod 0775 /var/spool/mail/

Think that we have good reasons to think 1777 is harmful... do not take the easy way by setting 1777 on /var/spool/mail/; better fix your MTA or switch to Maildir/ (the latter is a much better idea by the way).

Cheers,
Ferdy