http://www.disciplina.net/howto/HOWTO-sguil.html seems to be down

When do you plan to commit OpenCA?
thx...m

thanks!

Dude.. I can't find your email address.

My email is listed, perhaps you can email me 1st?

I am happy to let the HOWTO be used in your magazine, if you are serious contact me via email and I can look to do some refining and give you a more suitable version.

Dude.. Can I have your permission to republish your article into Edition 3 of MalaysianOSS Magazine?

I did a high-to-medium level intro into using suspend2 in Edition 1 and progressed with a Power Management Howto in Edition 2.

I think your documentation on suspend2 with LVM and encryption would fit in nicely into Edition 3.

Can you see if it's possible for me to either use it as is or if you're willing to do a polish up/review for the Magazine?

Please let me know. Thanks

URL for the magazine is --> http://mag.my-opensource.org

I don't think it can be done like that. The basic issue is that for each of the component parts kolab has extensive patchsets, so that if I don't somehow lock the subcomponent versions I will be left trying to maintain mammoth patchsets against constantly revving packages. Currently the most elegant way I can think of doing it is to provite a single kolab package that will block its namesakes, at least this way I can effectively version lock, something which portage can't do right now. I am very interested in any ways you can think of to implement it using existing gentoo packages as that is my preferred method as well. I will certainly be staying away from using the openpkg setup they use and I will look to make kolab FHS compliant where possible.

oh, yeah. please get rid of Kolab in an ideal way - that is, making use of the already existing ebuilds for proftp, apache and co. I'd really like kolab working in, but I dislike the /kolab approach just because they think it's best for them(tm)