Bugzilla Bug 127966

bitpim has been updated to version 0.8.10.

Created an attachment (id=83361) [edit]
bitpim-0.8.10.ebuild

Updated ebuild for bitpim 0.8.10. Please note that copying the bitpim-0.8.08
ebuild will not work. Some changes were made in the RPM layout.

Could you please check bug 127079? 
Maybe you manage to create a source based ebuild for this package :)

I probably don't have time to look into doing that.

Unfortunately the incompatibility between >gtk+2.8.8 and this package is not
solved by this version.
I will remove this package from the portage unless someone step up and make
that source based ebuild.

I am working on it now. Compiling wxGTK 2.6.2 right now. It also depends on
wxpython 2.6.2.1, which is not in portage yet. I am also testing that ebuild.

Several dependancies. Watch out for bug 100296 apsw. Use the original version,
3.2.2-r1. 3.2.7 could not be found.

Created an attachment (id=83415) [edit]
bitpim-0.8.10-r1.ebuild

Source based ebuild for 0.8.10. The tarball is meant to be tagged from the
tagged svn.

Created an attachment (id=83416) [edit]
files/get_main_dir_fix.patch

Patch to find the right /usr/lib/BitPim-${PV} directory since we're not
creating an executable, but using the python code directly.

OK, here's your source ebuild. I did some testing, looked through my phone book
and files. Retrieved from the phone. My phone doesn't have write support yet. I
am using usb so that appears to work. The tarball is made by:

svn export https://svn.sourceforge.net/svnroot/bitpim/releases/0.8.10
bitpim-0.8.10
tar -cvjf bitpim-0.8.10.tar.bz2 bitpim-0.8.10

Try it, hopefully it works for you. Remember you need wxGTK 2.6.2, wxpython
2.6.2.1 and apsw 3.2.2-r1.ebuild. I suppose newer wxpython, wxGTK and apsw will
work. The newer apsw tarball could not be found, I didn't try very hard.

When you've verified this and some others have tested, submit it upstream,
would you? That ebuild they have now is no good.

Created an attachment (id=83422) [edit]
bitpim-0.8.10-r1.ebuild

Added a .desktop file so it shows up in DE menus.

Created an attachment (id=83905) [edit]
bitpim-0.8.11.ebuild

Updated ebuild for 0.8.11. Create tarball with:
svn export https://svn.sourceforge.net/svnroot/bitpim/releases/0.8.11
bitpim-0.8.11
tar -cvjf bitpim-0.8.11.tar.gz bitpim-0.8.11

Any comment on this? Doesn't work? Works great? Waiting on dependancies to get
into portage??

Created an attachment (id=83906) [edit]
files/get_main_dir_fix.patch

I've already fixed the bug 100296 and now I'm waiting for bug 121856 to be
fixed.

Created an attachment (id=84457) [edit]
bitpim-0.8.12.ebuild

ebuild for latest release

Created an attachment (id=84458) [edit]
files/get_main_dir_fix.patch

I am a little confused about the necessity of including
http://sourceforge.net/projects/python-dsv into this ebuild.
According to the project home page, python-dsv is "CSV file importer/exporter
with heuristics for determining file format + optional wxPython dialog".
Is this thing required by bitpim?

Yes, python-dsv is required by bitpim. bitpim does import and export of CSV
files (amoung other formats) and uses this library. It should be a separate
ebuild but it is not longer being developed, mostly because it has all the
features it intended to implement and apparently no bugs. Bug 57323 filed to
include python-dsv in portage states it will not be included because it is not
actively developed. It is resolved as won't fix. Therefore I included it here.

ah, CSV not CVS!
okay, I will add the dev-python/dsv package to portage and set mobile-phone as
herd.

Created an attachment (id=84866) [edit]
bitpim-0.8.12.ebuild

Please test this version and see what needs to be fixed/improved.

Where is bitpim.desktop?

Created an attachment (id=84875) [edit]
bitpim.desktop

Right here ;)

Works good here exception there is ${RLOC} in the bitpim.desktop file. Is that
going to get resolved correctly? I thinking not.

Created an attachment (id=84907) [edit]
bitpim-0.8.12-get_main_dir.patch

Created an attachment (id=84908) [edit]
bitpim-0.8.12.ebuild

I've reverted the bitpim.desktop installation part to your implementation.

This ebuild has some QA issues:
QA Notice: the following files contain executable stacks
 Files with executable stacks will not work properly (or at all!)
 on some architectures/operating systems.  A bug should be filed
 at http://bugs.gentoo.org/ to make sure the file is fixed.
RWX --- --- usr/lib/bitpim-0.8.12/helpers/bmp2avi.lbin
RWX --- --- usr/lib/bitpim-0.8.12/helpers/pngtopnm.lbin
RWX --- --- usr/lib/bitpim-0.8.12/helpers/pnmtopng.lbin
RWX --- --- usr/lib/bitpim-0.8.12/helpers/ppmquant.lbin

I've asked the author of bitpim to help us fix those warnings and I am waiting
for his reply.

Created an attachment (id=85047) [edit]
bitpim-0.8.12-gentoo.patch

Created an attachment (id=85048) [edit]
bitpim-0.8.12.ebuild

This version fixed the *.lbin problems by using the variant of those programs
available through media-video/ffmpeg and media-libs/netpbm packages.

However, the bitpim program refuses to quit. After I close it, the console from
which I launched it displays:
...
not returning a bitmap for wxART_MISSING_IMAGE
BEGIN EXCLUSIVE TRANSACTION
END TRANSACTION
BEGIN EXCLUSIVE TRANSACTION
END TRANSACTION
Failed to get outlook
BEGIN EXCLUSIVE TRANSACTION
END TRANSACTION
setting windows/AutoSyncSettingsDialog to position 631, 472
setting windows/MainWin to position 151, 43 - size 1440 x 1080
7601 seconds till midnight
detectphone:sleeping 0

and it just sits there. Only Ctrl-C close the program.
Can anyone help me with this last issue?

FYI, the quit problem has always happened to me, whether using the RPM or this
compiled version, so it's not something specific to the ebuild. I'd be willing
to try any debugging procedures.

just svn exported 0.8.12 and compiled fine. I will try running it when I get
home.

I need someone to actually test the last ebuild before I can submit it to the
tree...

Works here.

Version has been submitted to the tree and the tarball has been posted for
inclusion on distfiles mirrors.

One thing is sure. This is the most laborious bug that I've ever encountered.
Thanks to all that helped me crack this, but most of all, thank you Pat!