On Jun 24, 2016, at 03:14 AM, Harshit Bansal wrote:
>I was trying to populate the two default styles in the database. For
>this purpose, I was trying to use ConfigurationUpdatedEvent as used in
>the earlier style manager but I am recieving following error:
>AttributeError: No section or category named db.
>It seems that the database layer hasn't got initialized by the time
>this event was fired. Is there any way of fixing this or any other way
>using which I can populate the database when mailman starts?
Getting the initialization sequence correct is pretty tricky, and it's true
that the configuration subsystem is initialized before the database connection
is created. If you think about it, it has to be this way since there are
settings in the config files that control how the database is set up.
What I think this means for you is that you can't use the
ConfigurationUpdatedEvent to set up your stylets until the database is set
up. Unfortunately, right now there aren't any events fired when
initialization is completely, but just the other day Aurelien and I sketched
out an event-based plugin mechanism for better HK integration, and one of the
things I realized we needed was some additional event notification for the
various stages of initialization.
Right now, your best hope is to use the [mailman]post_hook which gets run
during initialize_3() and is guaranteed to be run after both the configuration
subsystem and the database connection is set up. Eventually the pre_hook and
post_hook will be deprecated because they aren't really set up well for
plugins, and we'll have events for the various phases of initialization, so
you could register a handler for one of those events.
If you decide to keep the ConfigurationUpdatedEvent handler (e.g. because you
want to do other stylet things if the configuration changes once the system is
up and running), just check for the existence of the config.db attribute, or
catch the AttributeError. If the attribute is missing, you know the
ConfigurationUpdatedEvent is too early for your purposes.
Hope that helps.
I was trying to populate the two default styles in the database. For
this purpose, I was trying to use ConfigurationUpdatedEvent as used in
the earlier style manager but I am recieving following error:
Traceback (most recent call last):
line 87, in setUp
line 118, in initialize_1
line 102, in load
line 125, in _post_process
line 31, in notify
line 105, in handle_ConfigurationUpdatedEvent
line 85, in wrapper
return function(args, config.db.store, *args[1:], **kws)
line 87, in __getattr__
return getattr(self._config, name)
line 513, in __getattr__
raise AttributeError("No section or category named %s." % name)
AttributeError: No section or category named db.
It seems that the database layer hasn't got initialized by the time
this event was fired. Is there any way of fixing this or any other way
using which I can populate the database when mailman starts?
I am trying to connect hyperkitty to mailman. I have cloned and set up
mailman-hyperkitty and made changes in the mailman_hyperkitty.cfg and
mailman.cfg files. But, still I am unable to see anything in
hyperkitty(except the login page).I have injected mails to a list using
mailman inject -f email.txt test(a)example.net but couldn't see anything
there except the login page. "No archived lists yet" is shown there.
I checked the MailingList model in hyperkitty through command line and
found that it is empty.
On 06/21/2016 01:39 AM, Nischay Singh wrote:
> I read the guidelines on the website and found that the bugs are classified
> for beginners. Can someone please tell me where to look for such bugs.
Go to <https://gitlab.com/groups/mailman/issues> and look for issues
tagged 'beginner friendly'.
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Hi all! This is Nischay. I'm new to the open source community. Looking
forward to actively contributing to mailman.
I read the guidelines on the website and found that the bugs are classified
for beginners. Can someone please tell me where to look for such bugs.
Student B.E.(Hons) Computer Science
Aditya Divekar writes:
> So should a new conversation be started with Mark for
> our request?
I/we need to find out exactly what we need. We may want to do this
through email-test.python.org (no-existent, for example, python.org is
the relevant part, or maybe a private domain of someone's), but we
have to be careful that it doesn't conflict with other uses.
> That sounds good! The `mail` keyword gave an idea -
I think that would need to be shortened, but mailauth would work and
has a good rhythm. :-) Of course it may be "taken".
> I had read on the arc list that an OpenARC implementation was being
> developed by Murray Kucherawy. So I suppose that we may have the
> news of it being released on the list soon.
Yes, but Murray's OpenDKIM is a C library, and I expect OpenArc is
too. I don't think we should be using a C library because we're not
an MTA, and I suspect it will be making assumptions (eg, availability
of SPF) that we shouldn't.
In any case, the more independent implementations the better.
Aditya Divekar writes:
> So if we have a domain name associated with the ip, I'll go ahead
> and make the TXT records. Else, we'll have to create a new one.
> I'm not aware of any way to avoid this. Let me know if you are
> aware of any :)
Ah, that's a problem. I don't have control of the DNS yet. We'd need
to interact with Mark. Anyway it's too late for this one, there were
procedures to be taken earlier in the week. I'll get you on the
arc-interop list, there should be another one in the summer at the
pace they've been going.
> Yes, I went ahead and made the changes.
> I have a separate module 'arcpy' installed in my python
> dist-packages now which is basically the refactored 'dkimpy'
> package. I don't think its the best of names since it doesn't give
> the idea of presence of DKIM signing/verifying features. Any ideas
> for the same?
Not really. Keywords that might be useful aside from ARC, DKIM, and
DMARC: mail, post, verify, track, key, sign, identity.
Ah -- one brainstorm -- kimpy = "key identified mail.py".
As far as words go, you could just keep dkimpy, too, since ARC depends
on domain keys for its semantics, as well as on DKIM for its signing
protocol. "adkimpy"? Lots of double meanings there: Aditya, ARC,
augmented, domain, divikar. :-)
I was surprised by the news, but Google also chose dkimpy for its
implementation of ARC. I haven't had time to look at it, but maybe
early next week (not publicly licensed, sorry, no URL).
I'm sorry that I haven't responded before, it's been very busy
catching up to $DAYJOB since getting back.
> Now the next step would be to change the namespace and make it more
> general to accommodate the ARC capability. That is the module now
> provides the capability for ARC protocol implementation but still
> retains its 'DKIM' namespace. Since this would involve quite a few
> changes, and could easily break the setup, I would like your
> thoughts on this if there are any good practices to follow here.
I don't understand what you're worried about. Of course if you change
all the names, especially with some sort of automatic process, there's
a pretty good chance of introducing typos. We fix them as we find
them, that's all.
> The way I can think of doing this is to grep all files and change
> the names and then clear all the cache files.
Do you mean __pycache__? That will happen automatically for all files
with updated API calls. If you haven't updated the source to use the
changed API, the calls will break anyway. The only time this is a
worry is if you repurpose an existing name to different semantics, and
the answer there is "don't do that," because it's problematic anyway.
But these will be new names, so shouldn't cause that kind of problem.
I have a server with a fixed IP which could just pipe mail to a Python
script that reads it and passes the message to the ARC module for
processing. Then the script can send it back out if necessary.