Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000157 [obex-data-server] General major always 2009-02-10 10:43 2011-11-24 00:00
Reporter yelo3 View Status public  
Assigned To skirsdeda
Priority normal Resolution open  
Status assigned   Product Version 0.4.3
Summary 0000157: nokia: BT hang when copying files
Description versions 0.4.3 and 0.4.4
I'm using gvfs to mount and browse my nokia 6630. Then I use gnome-terminal to access it.

whenever I copy a file to my home directory (and also other destinations) the terminal hangs (the same if using nautilus) without any type of debuggung infirmation. To make it come back I have to disable BT on my nokia phone.

I don't know how to obtain further debug, can you help me?
thanks
Additional Information
Tags No tags attached.
Attached Files log file icon ods.log [^] (8,879 bytes) 2009-02-10 14:32
? file icon ods-session-test.py [^] (5,395 bytes) 2009-02-10 23:39
? file icon obex.debug [^] (32,435 bytes) 2009-02-12 22:43

- Relationships

-  Notes
(0000540)
skirsdeda (administrator)
2009-02-10 13:38

By "terminal" do you mean you are running obex-data-server --no-daemon? The best you can do is post output from this and optionally you could get a backtrace from gdb (so that we would see the place in code where it hangs).
(0000541)
yelo3 (reporter)
2009-02-10 14:15

Well, no. I'm using gvfs to mount, and the directory ~/.gvfs from the terminal.

Is is possible to use obex-data-server to browse the phone, so that I can identify if the problem is in o-d-s or gvfs?
(0000542)
skirsdeda (administrator)
2009-02-10 14:20
edited on: 2009-02-10 14:21

you do it like this:
1) killall obex-data-server
2) obex-data-server -n
In another terminal:
3) /usr/libexec/gvfsd -r

Then you copy the output of both ods and gvfsd.

(0000543)
yelo3 (reporter)
2009-02-10 14:27

I managed to start it using --no-daemon as you suggested.
(0000544)
yelo3 (reporter)
2009-02-10 14:32

Now, how can I get a backrace from gdb?
(0000545)
skirsdeda (administrator)
2009-02-10 14:39

gdb obex-data-server
>run -n

When it "hangs", you press Ctrl+c and
>bt

This will give you backtrace. However obex-data-server has to have debug symbols compiled into it (using --enable-debug).
(0000546)
yelo3 (reporter)
2009-02-10 15:05

I don't think I have --enable-debug but anyway this is what I get. Should I recompile with it?

^C Message: io callback
---Type <return> to continue, or q <return> to quit---bt
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7b36710 (LWP 13641)]
0xb7f57430 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f57430 in __kernel_vsyscall ()
#1 0xb7cd2a3b in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7e969cb in g_poll () from /usr/lib/libglib-2.0.so.0
0000003 0xb7e89172 in ?? () from /usr/lib/libglib-2.0.so.0
0000004 0xb7e89802 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
0000005 0x080518eb in ?? ()
0000006 0xb7c0f775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
0000007 0x0804ce81 in ?? ()
(0000547)
skirsdeda (administrator)
2009-02-10 15:09

No need for --enable-debug in this situation. It seems that what actually hangs is gvfs obexftp backend itself. So output of '/usr/libexec/gvfsd -r' would be more helpful in this case.
(0000548)
yelo3 (reporter)
2009-02-10 15:15

and this is the output of gvfsd -r:

- do_query_info
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x98025f8 (GVfsJobQueryInfo)
+ do_query_info, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper
send_reply(0x98025f8), failed=0 ()
backend_dbus_handler org.gtk.vfs.Mount:QueryInfo
Queued new job 0x9802648 (GVfsJobQueryInfo)
- do_query_info
+ do_query_info, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper
send_reply(0x9802648), failed=0 ()
- do_query_info
backend_dbus_handler org.gtk.vfs.Mount:OpenForRead
Queued new job 0x9805090 (GVfsJobOpenForRead)
+ do_open_for_read, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
+ _query_file_info_helper, filename: /C:/Nokia/Sounds/Digital/Lo chiamavano trinità.mp3
- _query_file_info_helper
(0000549)
yelo3 (reporter)
2009-02-10 15:17

Which when I disconnect BT ends with:
** Message: ErrorOccurred
** Message: Error name: org.openobex.Error.LinkError
** Message: Error message: Connection error
** Message: link lost to remote device
(0000550)
yelo3 (reporter)
2009-02-10 15:22

the gvfsd stacktrace is the same of obex-data-server
(0000551)
skirsdeda (administrator)
2009-02-10 15:32

It seems that you have non-english character in filename ('à'). Does the same thing happen with filenames without non-engligh characters?
(0000552)
yelo3 (reporter)
2009-02-10 15:38

I tried to transfer "roma3.bmp" with the same results (I've not tried the backtraces, only the hangs)

is it possible that the problem is the name of "C:" directory?
Are you sure that it is a gvfs prpblem?
Can I test file trasfter without using gvfs?
(0000553)
skirsdeda (administrator)
2009-02-10 15:41

"C:" directory is definitely not causing this problem.
Now I'm not so sure it's gvfs problem :)
You could test without gvfs. It will be a bit trickier. I'll post you the instructions soon.
(0000554)
yelo3 (reporter)
2009-02-10 15:51

Thank you very much! I really enjoy this quick support.
I hope it's not gvfs, since the support there is really slow
(0000555)
skirsdeda (administrator)
2009-02-10 16:02

I have attached ods-session-test.py script here. You will need to edit it before running.
Open it and change:
bt_address to you device's bluetooth address
folder_to_go_to to some folder in your device (only one level, so you could use 'C:' for example)
file_to_send to some local file (full path)

Then run this script without any arguments, e.g. ./ods-session-test.py
It will test all the capabilities of your device in one go.
(0000556)
yelo3 (reporter)
2009-02-10 16:39

I removed the exit() at line 28 because it caused the exit of the program after printing "0"

now the output is:
0
Session object: /org/openobex/session0

nothing else
(0000557)
yelo3 (reporter)
2009-02-10 16:43

and this in obex-data-server

** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Session created by: :1.106
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 32 (OK, Success)
** Message: Version: 0x10. Flags: 0x00 OBEX packet length: 65535

** Message: session_connect_result_cb
(0000558)
skirsdeda (administrator)
2009-02-10 19:09

So now I have the suspicion that OBEX Connect command fails because it sends default FTP uuid. This PC Suite service might require it's own UUID in connect command. I'll try to implement this and let you know when it's done.
(0000559)
yelo3 (reporter)
2009-02-10 19:21

Don't know if it helps, but when using syncml I have to pass the identifier "PC Suite"
(0000560)
skirsdeda (administrator)
2009-02-10 21:38

Please check with newest ods svn. Now it should use correct UUID for OBEX Connect.
(0000561)
yelo3 (reporter)
2009-02-10 22:38

Now it does not connect: I tried 2 times

** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Using Nokia PC Suite services UUID for CMD_CONNECT
** Message: Session created by: :1.238
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 68 (Not found)
** Message: session_connect_result_cb
** Message: session closed
** Message: Removing listened DBUS name :1.238 (object: /org/openobex/session0)
** Message: Parsed[0]: ftpistened DBUS names list
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Using Nokia PC Suite services UUID for CMD_CONNECT
** Message: Session created by: :1.242
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 68 (Not found)
** Message: session_connect_result_cb
** Message: session closed
** Message: Removing listened DBUS name :1.242 (object: /org/openobex/session1)
** Message: Removed from listened DBUS names list
** Message: closing connection
(0000562)
skirsdeda (administrator)
2009-02-10 22:55

FAIL :)
But with ods 0.4.4 using nautilus you get folder listings, right? It's only file sending that doesn't work.
(0000563)
yelo3 (reporter)
2009-02-10 22:59

with the ubuntu package 0.4.4-0ubuntu1 I can browse well. Also sending files works, using both copy/paste and the bluetooth applet. Only retreiving the file does not work
(0000564)
skirsdeda (administrator)
2009-02-10 23:02

Try running ods-session-test.py with using ods 0.4.4. The problem is probably in gvfs..
(0000565)
yelo3 (reporter)
2009-02-10 23:12

As I've already told you, ods-session-test.py has 2 problems:
- it exits after checking the USB connections
- it hangs waiting for the 'connected' event

could you please see if you made an error in the code?
(0000566)
skirsdeda (administrator)
2009-02-10 23:39

Sorry, I'm stupid today :D

Reattached fixed ods-session-test.py.
(0000567)
yelo3 (reporter)
2009-02-10 23:44

Hang when transferring file:

Session object: /org/openobex/session4
Connected
>>> RetrieveFolderListing()
<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <folder name="C:" user-perm="RW" mem-type="DEV" label="Memoria telefono"/>
   <folder name="E:" user-perm="RW" mem-type="MMC" label="Memory card"/>
</folder-listing>
>>> GetCurrentPath()
/
>>> ChangeCurrentFolder(C:)
>>> RetrieveFolderListing()
<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <parent-folder />
   <folder name="cache" modified="20050101T192432Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="LOGS" modified="20050101T192434Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="mmsvar" modified="20050101T192430Z" user-perm="RWD" mem-type="DEV"/>
   <folder name="Nokia" modified="20050101T192430Z" user-perm="RWD" mem-type="DEV"/>
</folder-listing>
>>> CreateFolder(Nonsense)
>>> GetCurrentPath()
C:/Nonsense/
>>> ChangeCurrentFolderBackward()
>>> GetCurrentPath()
C:/
>>> DeleteRemoteFile(Nonsense)
>>> SendFile(/home/yelo3/gmon.out)
>>> IsBusy()
1
Transfer started (gmon.out, /home/yelo3/gmon.out, 45747)
>>> GetTransferInfo()
-- Size = 45747
-- RemoteFilename = gmon.out
-- LocalPath = /home/yelo3/gmon.out
-- Time = 200
Progress: 100 %
Progress: 100 %
Transfer completed
>>> IsBusy()
0
>>> CopyRemoteFile(gmon.out, /home/yelo3/gmon_1.out)
Progress: 0 %
(0000568)
skirsdeda (administrator)
2009-02-10 23:48

And ods output for that?
(0000569)
yelo3 (reporter)
2009-02-10 23:52

Really similar: it ends with lots of
** Message: io callback
(0000570)
skirsdeda (administrator)
2009-02-10 23:57

Ok, then just try running ods-session-test with a file larger than 65535 bytes.
(0000571)
yelo3 (reporter)
2009-02-11 00:07

Again the file (6 Mb) is transferred but cannot be retreived
(0000572)
skirsdeda (administrator)
2009-02-11 00:24

What a sad day today :( When fixing ods-session-test I discovered SEGFAULT in openobex and I still can't figure out this bug. The only thing that strikes me is that your Nokia requires 65535 packet length (which is a maximum and is rarely used). I remember testing ods with this packet length by sending from ods to ods and there were some hangs AFAIK. That's why ods uses 32767 byte packet length. To sum up, this bug will need some peculiar investigation :) Thanks for your superb cooperation, I'll let you know when I figure smth out.
(0000573)
yelo3 (reporter)
2009-02-11 00:41

I also had one segfault using the svn version... That's why I really hate C in favour to C# or Java!
anyway where did you see that my nokia requires 65535 packets? the result with a larger file was exactly the same

At home I have other nokia phones to test, but I'll be back on friday. In this time we can still continue to test my 6630. Anyway I remember that in the past the gnome-vfs-obexftp backend used to work, so I don't think my nokia is broken
(0000574)
skirsdeda (administrator)
2009-02-11 00:44

You can see in ods.log that your Nokia suggests 65535 packet length when connecting.
(0000575)
skirsdeda (administrator)
2009-02-11 00:53

BTW, I also favour C# and Java but we have to wait at least 10 years until libraries are developed using high level languages :) And having in mind that Apple uses objective C exclusively (and GNOME prefers pure C), maybe even more years :D
(0000576)
yelo3 (reporter)
2009-02-11 01:00

I think C# is quite complete now. It has glib, gtk, dbus...
Could this app be written using it? or the usb & bt libraries are not present in c#?
(0000577)
skirsdeda (administrator)
2009-02-11 02:00

While Bluez DBus API could be used in C#, no C# bindings exist for libbluetooth, openobex and libusb. And openobex has such a bad design that writing any bindings for it would be plain stupid :D
(0000578)
yelo3 (reporter)
2009-02-11 13:25

just for a test I used windows with nokia pc suite, and it worked.

I also tried on linux using obexftp
obexftp -b "Nokia 6630" -B 12 -g E:/gmon.out
which worked too
(0000579)
skirsdeda (administrator)
2009-02-11 13:46

It worked with obexftp probably because it doesn't care about packet length. It probably uses the same default all the time.
(0000580)
yelo3 (reporter)
2009-02-11 13:50

Where can I change packet length in the source, so that I can test if it works?
(0000581)
yelo3 (reporter)
2009-02-11 14:07

... I changed the file and this time worked... (I'm running svn now)
it seems related on the file content maybe?

I was able to retreive a text file of 9 bytes (there are some errors but it worked) the two files have the same content!!!

this is the final part of the output of ods-test:
>>> CopyRemoteFile(test.txt, /home/yelo3/test_1.txt)
Progress: 0 %
Transfer started (test.txt, /home/yelo3/test_1.txt, 0)
>>> GetTransferInfo()
-- Size = 0
-- RemoteFilename =
-- LocalPath =
Progress
Transfer completed
>>> DeleteRemoteFile(test.txt)
>>> SendFile(/home/yelo3/test.txt)
>>> Cancel()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Progress
Transfer completed
>>> ChangeCurrentFolderToRoot()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
>>> GetCurrentPath()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
False
>>> GetCapability()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
False
>>> Disconnect()
Failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.





and this is obex-data-server -n:
** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: Connect in progress
** Message: Connected
** Message: Session created by: :1.234
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 0, response 32 (OK, Success)
** Message: Version: 0x10. Flags: 0x00 OBEX packet length: 65535

** Message: session_connect_result_cb
** Message: LOCK ods_session_get_by_type
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_get_by_type
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: Writing to buf
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_setpath
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 5, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_delete_remote_file
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_send_file_ext
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: read 0 bytes (EOF)
** Message: UNLOCK ods_session_send_file_ext
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: LOCK ods_session_copy_remote_file_full
** Message: UNLOCK ods_session_copy_remote_file_full
** Message: io callback
** Message: event: 0

** (obex-data-server:12690): WARNING **: PROGRESS: 0
** Message: io callback
** Message: event: 9
** Message: There is some data
** Message: event: 9
** Message: event: 3
** Message: obex_request_done: command 3, response 32 (OK, Success)

** (obex-data-server:12690): WARNING **: MODTIME: -1
** Message: LOCK ods_session_delete_remote_file
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: UNLOCK obex_request_done
** Message: LOCK ods_session_send_file_ext
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: event: 8
** Message: obex_writestream
** Message: writestream from File: 7
** Message: read 0 bytes (EOF)
** Message: UNLOCK ods_session_send_file_ext
** Message: LOCK ods_session_cancel
** Message: io callback
** Message: event: 3
** Message: obex_request_done: command 2, response 32 (OK, Success)
** Message: LOCK ods_session_setpath
(0000582)
yelo3 (reporter)
2009-02-11 14:13

It also works with jpg files.
(0000583)
yelo3 (reporter)
2009-02-11 14:24

Alsu using gvfs works, but lets me do only 1 transfer, then it hangs.

Maybe it's exactly the same thing which happens using the yout test script: after the transfert nothing else will work.
(0000584)
yelo3 (reporter)
2009-02-11 14:31

It also works with 0.4.4-0ubuntu1 ubuntu original............
I really can't understand!!!! I did exactly the same operations of yesterday from nautilus!
(still only 1 file copy works)
(0000585)
skirsdeda (administrator)
2009-02-12 18:44

I tested with maximum packet length and something very wrong happens inside openobex. The only way to fix this is to actually analyze what's happening there and believe me, openobex code base is really difficult to understand :)
(0000586)
yelo3 (reporter)
2009-02-12 18:50

My tests were done without any change in packet length. I'm using plain ubuntu packages.
Are you are able to understand what happens when the file transfert ends, and why dbus will not answer
(0000587)
skirsdeda (administrator)
2009-02-12 21:23

It turns out that openobex fails to receive packets larger than 43344 bytes! I don't know where this magic number comes from yet :) openobex is just a huge pain in the ass.
(0000588)
skirsdeda (administrator)
2009-02-12 21:36
edited on: 2009-02-12 21:47

You could confirm this by compiling openobex with debug output enabled. You would have to get openobex source and do smth like this:
./bootstrap
./configure --prefix=/usr --enable-debug
then change OBEX_DEBUG to 4 in config.h
make
make install

Then ods output will have openobex debug output as well.

(0000589)
yelo3 (reporter)
2009-02-12 22:43

I downloaded openobex-1.4 from bluez site
./bootstrap was not present, so I passed to ./configure etc.

I executed the usual things and collected the output (I killed obex-data-server as soon as the first dbus error), which I will attach now
(0000594)
yelo3 (reporter)
2009-03-05 12:28

Just to inform you, also fedora 11 alpha has this issue
(0001761)
hamelg (reporter)
2011-11-24 00:00

Hello,
I have a Nokia N70 and I had this issue. I use obex-data-server 0.4.6.
I have enabled debug mode in openobex library and I have compared the output with the output of obexftp which works fine. I found out the default MTU with obexftp is 1024. MTU in obex-data-server is 32767 and it's just too big for my Nokia !
I have lowered the MTU in ods-obex.h like this :
#define ODS_DEFAULT_RX_MTU 8192
#define ODS_DEFAULT_TX_MTU 8192
and this issue was definitively fixed :)

- Issue History
Date Modified Username Field Change
2009-02-10 10:43 yelo3 New Issue
2009-02-10 13:38 skirsdeda Note Added: 0000540
2009-02-10 14:15 yelo3 Note Added: 0000541
2009-02-10 14:20 skirsdeda Note Added: 0000542
2009-02-10 14:21 skirsdeda Note Edited: 0000542
2009-02-10 14:27 yelo3 Note Added: 0000543
2009-02-10 14:32 yelo3 File Added: ods.log
2009-02-10 14:32 yelo3 Note Added: 0000544
2009-02-10 14:39 skirsdeda Note Added: 0000545
2009-02-10 15:05 yelo3 Note Added: 0000546
2009-02-10 15:09 skirsdeda Note Added: 0000547
2009-02-10 15:15 yelo3 Note Added: 0000548
2009-02-10 15:17 yelo3 Note Added: 0000549
2009-02-10 15:22 yelo3 Note Added: 0000550
2009-02-10 15:32 skirsdeda Note Added: 0000551
2009-02-10 15:38 yelo3 Note Added: 0000552
2009-02-10 15:41 skirsdeda Note Added: 0000553
2009-02-10 15:51 yelo3 Note Added: 0000554
2009-02-10 15:59 skirsdeda File Added: ods-session-test.py
2009-02-10 16:02 skirsdeda Note Added: 0000555
2009-02-10 16:39 yelo3 Note Added: 0000556
2009-02-10 16:43 yelo3 Note Added: 0000557
2009-02-10 19:09 skirsdeda Note Added: 0000558
2009-02-10 19:17 skirsdeda Status new => assigned
2009-02-10 19:17 skirsdeda Assigned To => skirsdeda
2009-02-10 19:21 yelo3 Note Added: 0000559
2009-02-10 21:38 skirsdeda Note Added: 0000560
2009-02-10 22:38 yelo3 Note Added: 0000561
2009-02-10 22:55 skirsdeda Note Added: 0000562
2009-02-10 22:59 yelo3 Note Added: 0000563
2009-02-10 23:02 skirsdeda Note Added: 0000564
2009-02-10 23:12 yelo3 Note Added: 0000565
2009-02-10 23:38 skirsdeda File Deleted: ods-session-test.py
2009-02-10 23:39 skirsdeda File Added: ods-session-test.py
2009-02-10 23:39 skirsdeda Note Added: 0000566
2009-02-10 23:44 yelo3 Note Added: 0000567
2009-02-10 23:48 skirsdeda Note Added: 0000568
2009-02-10 23:52 yelo3 Note Added: 0000569
2009-02-10 23:57 skirsdeda Note Added: 0000570
2009-02-11 00:07 yelo3 Note Added: 0000571
2009-02-11 00:24 skirsdeda Note Added: 0000572
2009-02-11 00:41 yelo3 Note Added: 0000573
2009-02-11 00:44 skirsdeda Note Added: 0000574
2009-02-11 00:53 skirsdeda Note Added: 0000575
2009-02-11 01:00 yelo3 Note Added: 0000576
2009-02-11 02:00 skirsdeda Note Added: 0000577
2009-02-11 13:25 yelo3 Note Added: 0000578
2009-02-11 13:46 skirsdeda Note Added: 0000579
2009-02-11 13:50 yelo3 Note Added: 0000580
2009-02-11 14:07 yelo3 Note Added: 0000581
2009-02-11 14:13 yelo3 Note Added: 0000582
2009-02-11 14:24 yelo3 Note Added: 0000583
2009-02-11 14:31 yelo3 Note Added: 0000584
2009-02-12 18:44 skirsdeda Note Added: 0000585
2009-02-12 18:50 yelo3 Note Added: 0000586
2009-02-12 21:23 skirsdeda Note Added: 0000587
2009-02-12 21:36 skirsdeda Note Added: 0000588
2009-02-12 21:47 skirsdeda Note Edited: 0000588
2009-02-12 22:43 yelo3 Note Added: 0000589
2009-02-12 22:43 yelo3 File Added: obex.debug
2009-03-05 12:28 yelo3 Note Added: 0000594
2011-11-24 00:00 hamelg Note Added: 0001761


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker