Discussion:
[Bitpim-devel] 0.7.14 under Linux
Stephen Wood
2004-07-10 00:27:19 UTC
Permalink
As Roger hinted, 0.7.14 does not work under Linux, at least Fedora Core
1. BitPim will start up, and the menus and tabs work fine. But if I
initiate a transfer, the hour glass just spins with nothing showing up
in the Log pane.

I am in the process of getting python2.3, wxwidgets and cx_freeze
updated on my development machine, so I'll try building my own RPM to
see if I can help understand this.

Stephen
Drew Bertola
2004-07-10 01:06:57 UTC
Permalink
Post by Stephen Wood
As Roger hinted, 0.7.14 does not work under Linux, at least Fedora Core
1. BitPim will start up, and the menus and tabs work fine. But if I
initiate a transfer, the hour glass just spins with nothing showing up
in the Log pane.
I'm also seeing something similar under FC2. Reverting back to 0.7.13
set everything straight again (at least I could send data to the phone).

One thing I've never found an answer to: often, when I try to start
bitpim, I get:

# bitpim
Fatal Python error: Invalid magic
Aborted

Any quick way to fix that? (I did search a few google pages for similar
errors, but nothing came of it).

--
Drew
Richard Hendershot
2004-07-11 09:40:37 UTC
Permalink
Post by Drew Bertola
Post by Stephen Wood
As Roger hinted, 0.7.14 does not work under Linux, at least Fedora Core
1. BitPim will start up, and the menus and tabs work fine. But if I
initiate a transfer, the hour glass just spins with nothing showing up
in the Log pane.
I'm also seeing something similar under FC2. Reverting back to 0.7.13
set everything straight again (at least I could send data to the phone).
One thing I've never found an answer to: often, when I try to start
# bitpim
Fatal Python error: Invalid magic
Aborted
Any quick way to fix that? (I did search a few google pages for similar
errors, but nothing came of it).
--
Drew
Drew, I've taken to reinstalling from the rpm using replacepkgs. I get
this complaint about Invalid Magic on each new day. Fedora Core 2,
BitPim 0.7.13.

HTH!
-rsh

ps-thanks guys for the software! I didn't know it was available when I
bought my LG VX6000 (US Cellular) but I now regularly use it at work
(Windows XP Pro) and home (aforementioned Linux) and take camera
pictures just as often as I feel like it... knowing I can sync my file
storage from my phone at any time. It let's me use my phone as a simple
PDA!
Roger Binns
2004-07-15 03:43:08 UTC
Permalink
It let's me use my phone as a simple PDA!
You can use the LG phones as a complete PDA. They have phonebook,
calendar, messenging, voice and text memos etc. BitPim will
eventually support all of that!

Roger
Richard Hendershot
2004-07-16 11:44:44 UTC
Permalink
Post by Roger Binns
It let's me use my phone as a simple PDA!
You can use the LG phones as a complete PDA. They have phonebook,
calendar, messenging, voice and text memos etc. BitPim will
eventually support all of that!
Roger
Agreed! The only thing really missing is synchronization with outlook
schedule. That's something, I understand, is in the map for BitPim. Oh
and BlueTooth, but that's not a BP issue ;)

I purchased two USB data cables so I would have one handy at work and at
home. I use FC2 Linux at home and WindowsXP at work. So when I think
of calendar and schedule synching, I'm really thinking of unifying
Outlook and Evolution Calendar and Tasks via my LG VX6000 as the master
device. Of course, anything that approaches that Ideal is fine by me!


-rsh
Drew Bertola
2004-07-15 21:57:33 UTC
Permalink
Post by Drew Bertola
One thing I've never found an answer to: often, when I try to start
# bitpim
Fatal Python error: Invalid magic
Aborted
Drew, I've taken to reinstalling from the rpm using replacepkgs.
I get this complaint about Invalid Magic on each new day. Fedora
Core 2, BitPim 0.7.13.
So, knowing this, I did a fresh install of 0.7.14-1 (on FC2), and, it
worked all day. Sure enough, the next day I got the "invalid Magic"
python error.

At that point, I captured a listing of all files in the rpm, then ran
rpm -V bitpim below, re-installed the same rpm and again captured a
listing. The diff between the two listings is also below.

w/ error:
# rpm --verify bitpim
S.5..... /usr/lib/bitpim-0.7.14/bp

after re-install:
# rpm --verify bitpim
[no problems]

diff of listings:
$ diff filelist_bitpim_fresh.txt filelist_bitpim_magic_error.txt 17c17
< -rwxr-xr-x 1 root root 7746233 Jul 9 19:30 /usr/lib/bitpim-0.7.14/bp
---
Post by Drew Bertola
-rwxr-xr-x 1 root root 924420 Jul 9 19:30 /usr/lib/bitpim-0.7.14/bp
So, that matches what we see from the rpm verify.

This is a hint. I need to dig further. Some things I need to look at
are:
- On which OSes does this occur? (only Fedora FC1 and FC2 available
here).
- Is this SMP only? (I'll test on my UP/FC1 box).
- What debugging tools will help sort this out?
--
Drew
Drew Bertola
2004-07-16 00:11:29 UTC
Permalink
Post by Drew Bertola
One thing I've never found an answer to: often, when I try to start
# bitpim
Fatal Python error: Invalid magic
Aborted
More investigation reveals that this is caused by the prelink that
occurs daily.

# grep -i bitpim /var/log/prelink.log
Prelinking /usr/lib/bitpim-0.7.14/bp

Why? I don't know. Any python gurus suggest a good fix?

Anyway, a work around is to turn off prelinking in
/etc/sysconfig/prelink.

--
Drew
Roger Binns
2004-07-16 05:04:00 UTC
Permalink
Post by Drew Bertola
More investigation reveals that this is caused by the prelink that
occurs daily.
# grep -i bitpim /var/log/prelink.log
Prelinking /usr/lib/bitpim-0.7.14/bp
Why? I don't know. Any python gurus suggest a good fix?
Anyway, a work around is to turn off prelinking in
/etc/sysconfig/prelink.
The bp file is actually the Python interpretter binary
with a zip file appended. I would suspect the prelinker
isn't actually realising that and ends up badly munging
the file. I'll mention this to the cx-Freeze author.

I still remain glad I didn't go anywhere near FC2 :-)

Roger
Richard Hendershot
2004-07-16 11:56:06 UTC
Permalink
Post by Drew Bertola
Post by Drew Bertola
One thing I've never found an answer to: often, when I try to start
# bitpim
Fatal Python error: Invalid magic
Aborted
Drew, I've taken to reinstalling from the rpm using replacepkgs.
I get this complaint about Invalid Magic on each new day. Fedora
Core 2, BitPim 0.7.13.
So, knowing this, I did a fresh install of 0.7.14-1 (on FC2), and, it
worked all day. Sure enough, the next day I got the "invalid Magic"
python error.
So, I'm not insane after all! ;)
Post by Drew Bertola
At that point, I captured a listing of all files in the rpm, then ran
rpm -V bitpim below, re-installed the same rpm and again captured a
listing. The diff between the two listings is also below.
# rpm --verify bitpim
S.5..... /usr/lib/bitpim-0.7.14/bp
# rpm --verify bitpim
[no problems]
$ diff filelist_bitpim_fresh.txt filelist_bitpim_magic_error.txt 17c17
< -rwxr-xr-x 1 root root 7746233 Jul 9 19:30 /usr/lib/bitpim-0.7.14/bp
---
Post by Drew Bertola
-rwxr-xr-x 1 root root 924420 Jul 9 19:30 /usr/lib/bitpim-0.7.14/bp
So, that matches what we see from the rpm verify.
This is a hint. I need to dig further. Some things I need to look at
- On which OSes does this occur? (only Fedora FC1 and FC2 available
here).
- Is this SMP only? (I'll test on my UP/FC1 box).
mine is a uniprocessor box. Dell Dimension 2400n. My work machine is
windows XP, a Dell 850, and I've not seen the problem there. If you need
details from that machine let me know what you need and I can get that
when I'm there.
Post by Drew Bertola
- What debugging tools will help sort this out?
--
Drew
--
Richard Hendershot <***@mchsi.com>
Roger Binns
2004-07-10 02:44:16 UTC
Permalink
Post by Stephen Wood
As Roger hinted, 0.7.14 does not work under Linux, at least Fedora Core
1. BitPim will start up, and the menus and tabs work fine. But if I
initiate a transfer, the hour glass just spins with nothing showing up
in the Log pane.
What it looked like to me is that the comms thread never runs.
The 0.7.14 distributed was built using cx-freeze 3.0

I have just rebuilt using cx-freeze 2.2 and it works fine on all
my test machines. Consequently I have uploaded that new build.
You can tell it apart from the first one by looking at the end
of the rpm version. -0 is cx-freexe 3.0 and -1 is cx-freexe 2.2.
The latter is what the BitPim home page links to.

The cx-freeze author did assure me that there were no threading
issues with cx-freeze 3.0 when I originally reported this. I
guess he was wrong :-)

Roger
Drew Bertola
2004-07-10 02:51:08 UTC
Permalink
Post by Roger Binns
I have just rebuilt using cx-freeze 2.2 and it works fine on all
my test machines. Consequently I have uploaded that new build.
You can tell it apart from the first one by looking at the end
of the rpm version. -0 is cx-freexe 3.0 and -1 is cx-freexe 2.2.
The latter is what the BitPim home page links to.
I'm getting a file not found error from:

http://osdn.dl.sourceforge.net/sourceforge/bitpim/bitpim-0.7.14-1.i386.rpm

I'll try again in a bit. I'm anxious to test and report back.

--
Drew
Roger Binns
2004-07-10 03:10:39 UTC
Permalink
Post by Drew Bertola
http://osdn.dl.sourceforge.net/sourceforge/bitpim/bitpim-0.7.14-1.i386.rpm
I'll try again in a bit. I'm anxious to test and report back.
I only checked the first stage of the download process which worked fine.
Normally osdn.dl has the files immediately on upload. I guess they are
taking a lot longer than normal this time.

I checked the other mirrors, and voxel does have it. Just replace osdn
with voxel in that URL and all will be fine.

Roger
Drew Bertola
2004-07-10 03:32:00 UTC
Permalink
Post by Roger Binns
Post by Drew Bertola
http://osdn.dl.sourceforge.net/sourceforge/bitpim/bitpim-0.7.14-1.i386.rpm
I'll try again in a bit. I'm anxious to test and report back.
I only checked the first stage of the download process which worked fine.
Normally osdn.dl has the files immediately on upload. I guess they are
taking a lot longer than normal this time.
I checked the other mirrors, and voxel does have it. Just replace osdn
with voxel in that URL and all will be fine.
Cool. Got it and I've verified that it works where 0.7.14-0 failed.
This is on FC2.

--
Drew
Loading...