Description of problem: On my up-to-date F12 system, with evolution and gbirthday installed, I'm not getting any birthdays reported. The contacts in evolution (in the 'Personal' address book, marked as default) mostly have dates of birth entered; these show up in the evolution calendar under 'Birthdays and anniversaries'. Version-Release number of selected component (if applicable): gbirthday-0.5.4-1.fc12.noarch evolution-2.28.0-2.fc12.x86_64 How reproducible: This is happening on all my computers (all with the same setup). Steps to Reproduce: 1. Install evo, set up some contacts, enter birthdays 2. Install gbirthday, set prefs to pick up from evo 3. Fend off complaints at having missed mother's birthday Actual results: Nothing from gbirthday Expected results: Birthdays reported Additional info: I don't know if it's relevant that I also have non-default address books in evolution.
Hi James, thanks for the bug report. It works her perfectly, and as far as I know on some other machines... Currently it parses any databases below ~/.evolution/addressbook/local/ with the python module 'bsddb' and not directly in gbirthday itself. Please post the output from 'find ~/.evolution/addressbook/local/'
.evolution/addressbook/local .evolution/addressbook/local/system .evolution/addressbook/local/system/Derek.changes.db .evolution/addressbook/local/system/addressbook.db.summary .evolution/addressbook/local/system/beagle-ZWQU99q1fkG5EEj0dbXXjA.changes.db .evolution/addressbook/local/system/beagle-o+aBSJM_w0+8JagzByEIaw.changes.db .evolution/addressbook/local/system/Derek2.changes.db .evolution/addressbook/local/system/addressbook.db .evolution/addressbook/local/system/beagle-V993x7ClzU++Z7GV1veN_g.changes.db .evolution/addressbook/local/1191259925.7916.10@kevin .evolution/addressbook/local/1191259925.7916.10@kevin/addressbook.db.summary .evolution/addressbook/local/1191259925.7916.10@kevin/beagle-ZWQU99q1fkG5EEj0dbXXjA.changes.db .evolution/addressbook/local/1191259925.7916.10@kevin/beagle-o+aBSJM_w0+8JagzByEIaw.changes.db .evolution/addressbook/local/1191259925.7916.10@kevin/addressbook.db .evolution/addressbook/local/1191259925.7916.10@kevin/beagle-V993x7ClzU++Z7GV1veN_g.changes.db .evolution/addressbook/local/1256213427.3537.0.dyndns.org .evolution/addressbook/local/1256213427.3537.0.dyndns.org/addressbook.db.summary .evolution/addressbook/local/1256213427.3537.0.dyndns.org/beagle-ZWQU99q1fkG5EEj0dbXXjA.changes.db .evolution/addressbook/local/1256213427.3537.0.dyndns.org/addressbook.db
Ah, OK. I know what the problem is, though I've no idea why it should be affecting me and no-one else. Evolution, on my machine at least, stores the birthday entry in the VCD as YYYYMMDD. But gbirthday is expecting YYYY-MM-DD. It's all going wrong when gbirthday tries to find a particular date, searching as '-MM-DD'. Nothing's being found, because the strings are in bdayKeys without the dashes in. The easiest way to fix this would presumably be to check for the format when it's read in from evolution (or other sources), and insert the dashes if it's YYYYMMDD. But why is this happening? Is it a locale thing? I have got export LC_TIME="en_DK.UTF-8" in my .bash_profile, because it seems to be the only way to get Evolution to display times in a 24h format. But I would be surprised if this affected how the dates were stored inside the database.
Strange... I currently try to get the contacts birthdays from gnome-python2-evolution, but without success... import evolution for title, book in evolution.ebook.list_addressbooks(): ebook = evolution.ebook.open_addressbook(book) for contact in ebook.get_all_contacts(): print contact.props.full_name, contact.props.birth_date contact.props.birth_date returns a EContactDate object, which has no methods to actually display the date.... Google does not help at all. But this would be the best way to fix any storing problems from evolution. If this does not work at all, I'll add the dashes.
If it's the Python equivalent of the EContactDate struct mentioned here: http://linuxart.com/projects/evolution/developer-doc/libebook/EContact.html then it will contain nothing more than .year, .month, .day. But then that's all you need, I think?
Yes, but there is: ''' struct EContactDate { int year; int month; int day; }; ''' and when getting the birth-date, you get a EContactDate, which has *no* methods like .year, .month and .day. If they where there, this would be done ;) Currently it works, with getting the vcard from evolution, but I guess, then you get the same wrong date format it's saved in the database. So probably not a solution for your problem. But maybe it does work with this. Can you please test it? The .rpm is at http://tomspur.fedorapeople.org/bug/gbirthday-0.5.4-2.fc12.noarch.rpm 'yum erase gbirthday && rpm -i gbirthday-0.5.4-2.fc12.noarch.rpm'
No, that didn't work, I'm afraid. (If you do go down the gnome-python2-evolution route, don't forget to add it as a dep in the spec. Currently it doesn't complain if it's not installed, and then crashes when gbirthday starts. But I've installed the python module and still no joy.)
By the way, if I run evo.py, I am getting entries like the following: Jørn Bjørnerem <EContactDate at 0x242fd60> BEGIN:VCARD VERSION:3.0 REV:2009-08-24T13:05:46Z UID:pas-id-4A3948850000005D X-EVOLUTION-FILE-AS:Bjørnerem\, Jørn BDAY:19751227 EMAIL;TYPE=INTERNET:blah EMAIL;TYPE=INTERNET:blah FN:Jørn Bjørnerem N:Bjørnerem;Jørn;;; END:VCARD I see what you mean--I tried getting it to return contact.props.birth_date.year but to no avail.
(In reply to comment #7) > (If you do go down the gnome-python2-evolution route, don't forget to add it as > a dep in the spec. Sorry, I thought, I've done that. It's done now in the next release. For now gbirthday reformats the YYYYMMDD into YYYY-MM-DD. Maybe in the future this can be avoided, when evolution supports .year. Will do the build, when infrastructure is working again (maybe in 2 hours). http://tomspur.fedorapeople.org/bug/gbirthday-0.5.5-1.fc12.src.rpm
Wrong link... http://tomspur.fedorapeople.org/bug/gbirthday-0.5.5-1.fc12.noarch.rpm
That works just great! Thanks! Maybe the methodless object should be filed as a bug against gnome-python2-evolution. It is a bit pointless providing something if you can't do anything with it (except test for None, I suppose).
gbirthday-0.5.5-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gbirthday-0.5.5-1.fc12
gbirthday-0.5.5-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gbirthday-0.5.5-2.fc12
gbirthday-0.5.5-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.