This affects me, too, since upgrading from 10.04 to 10.10. This is from
Evolution 2.28.x to 2.30.3
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/275952
Title:
Unread search folder removes
Public bug reported:
Binary package hint: evolution-data-server-dev
evolution-data-server dev 2.28.3.1-0ubuntu5 contains an upstream bug, as
far as I can see.
/usr/include/evolution-data-server-2.28/libedataserver/eds-version.h contains
#define EDS_MICRO_VERSION 3.1
and
#define
I listed steps 1,2,3 in my initial bug report: load an audio CD into
secondary slave IDE device, cancel gnome handler, fire up brasero and
get a segfault every time.
Doesn't seem to happen with data CDs, or with the secondary master IDE
device (dvd drive).
Hardware: primary IDE has two hard
Public bug reported:
Binary package hint: brasero
I'm getting a segfault on brasero startup on jaunty. My system is up to date.
I am running brasero 2.26.1-0ubuntu1 and libbrasero-media0 2.26.1-0ubuntu1
Rather like bug #335942, nautilus will also crash with a segfault.
I can reproduce this
** Attachment added: gdb-brasero.txt
http://launchpadlibrarian.net/28040868/gdb-brasero.txt
--
brasero segfault on startup
https://bugs.launchpad.net/bugs/388707
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to brasero in ubuntu.
--
** Attachment added: valgrind.log
http://launchpadlibrarian.net/28040876/valgrind.log
--
brasero segfault on startup
https://bugs.launchpad.net/bugs/388707
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to brasero in ubuntu.
--
Murray says I can't sync, but it's not clear whether this is just an
example of the known Edgy problems (i.e. with gnome-
pilot-2.0.14-0Ubuntu2) or something else. He could try installing the
packages I rolled (see gnome bug 365181, comment 14) and see if that
fixes matters.
Failing that, it's
There's little point in forwarding upstream.
AFAIK, it is not possible to 100% reliably determine the correct ttyUSB device,
so the visor/ttyUSB support in gnome-pilot is not going to improve (ie. upstream
would be WONTFIX).
The correct roadmap seems to be to move to using direct libusb support.
Yes, looks right.
Oddly there's one stray diff block I don't recognise:
--
@@ -1256,6 +1266,7 @@
gpcap_save_state (GnomePilotCapplet *gpcap)
{
GnomePilotCappletPrivate *priv;
+ GtkObjectClass *gppd_class;
priv = gpcap-priv;
See also the following upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=363102
... which contains a patch to evolution-data-server to prevent freeing of an
ical data structure by a background thread while the data is in use. This
seems to be the exact cause of the crashes I was getting
Clearly working :)
Mind you, I would say that, wouldn't I...
--
applet isn't transparent in transparent panels
https://launchpad.net/bugs/45297
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
probably an instance of upstream gnome bug 319076.
--
Copy from pilot works only the first time
https://launchpad.net/bugs/73149
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
The situation is improved in gnome-pilot 2.0.14/15, but not really fixed
or fixable.
IMO, it is not possible to robustly detect the correct ttyUSB port to
use. The /dev/pilot symlink is the best bet, but even then I've seen
situations in which it suddenly starts pointing to the wrong ttyUSB
In my case, I was getting crashes in evolution-data-server. It would appear to
be:
http://bugzilla.gnome.org/show_bug.cgi?id=319076
--
problems syncing calendar and todo list, adresses works
https://launchpad.net/bugs/19528
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
Public bug reported:
I was trying to rebuild evolution-data-server without optimisation, to
help track down a bug triggered by a gnome-pilot synchronisation with
the calendar conduit.
I am having trouble with the libical part of e-d-s. It appears that the
calendar/libical/configure script is
Thanks for the pointer. I'm away from my dev machine at the moment, but
I'll do as you suggest when I get a chance.
--
build error trying to build evolution-data-server from .dsc, .diff.gz, and
tarball
https://launchpad.net/bugs/73891
--
desktop-bugs mailing list
I set my sync options to copy from PDA, and got a crash while syncing
the calendar conduit. I did not have trouble with a copy from PDA in
the address or memo conduits.
I tried downgrading to the Edgy package and produced the same crashes.
So it seems to be a bug in the evolution calendar
https://launchpad.net/distros/ubuntu/+source/gnome-pilot/+bug/19528
--
gpilotd locks up my Palm Z22
https://launchpad.net/bugs/66355
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
There are two problems here.
When calendar doesn't crash, but just doesn't appear to sync, you've probably
got a case of:
http://bugzilla.gnome.org/show_bug.cgi?id=316370
When the caledar crashes, that looks to me like something different. It
is possible that it is a regression introduced with
I have built an unofficial Ubuntu package based on the recent fixes, which
should be suitable for Edgy. You can try them out from:
http://www.inference.phy.cam.ac.uk/mcdavey/downloads/
This build is not an official Ubuntu release. It is unsupported, but should
fix two specific issues with the
need to copy the other .server
file from /tmp/gp/lib/bonobo/servers/
Note, by the way, that /tmp/gp might well get cleared out on a reboot,
so if you want to keep this configuration for any length of time you may
want to install somewhere else :)
Matt
Matt Davey Never forget what a man says
Phil,
As mentioned by Daniel Holbach (2006-11-16 above), there is a testable
package uploaded to Feisty. That package will contain the patch. In addition
there's a link to the upstream bug at the top of this ticket and, as I
mentioned, that contains a link to a downloadable tarball.
The
I've seen this a few times, and what appears to be happening is that
/dev/pilot starts pointing to the 'wrong' ttyUSB device. When this
happens you'll see the pi_accept_to returned -202 messages (-202 means
'timeout' in pilot-link speak).
If this is a problem for you, you have two options:
1.
I agree with DB. Time to forward upstream to evo-conduits.
--
Wrong character in memo category after palm sync
https://launchpad.net/bugs/64575
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Hi Phil,
It looks as though gnome-pilot hasn't actually been built correctly. I don't
know what steps you took (I didn't give detailed instructions, because usually
people asking for patches and building packages are old hands at this stuff).
You say you built gnome-pilot 1.161, but 1.161
Looks like duplicate of bug # 66355
--
Fatal error on Palm during synchronization with Evolution
https://launchpad.net/bugs/71837
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Joel,
silly question, but there isn't any chance you've got two versions of gpilotd
on your system: one that you run from the command line and one that the applet
finds? There aren't any arguments that I can think of that would affect the
behaviour as you describe.
One thing to check is
This could have been forwarded to upstream evolution-conduits as an
improvement suggestion... It would be better if bogus data from the
palm didn't cause the app to throw an assert failure, but resulted in a
log message and skipping of the record, or some such. It's a rare
enough case, I guess.
Joel:
Indeed I only have one gpilotd. I attempted to get libusb working. -
that seems fine as i got
pilot-xfer -p usb: -l
to work. But I did have a question about
~/.gnome2/gnome-pilot.d/gpilot
I could not figure out what to set /dev/pilot to?
You should be able to set it to 'usb:'
There is more info attached to the upstream bug, but the summary so far
is:
some palmos devices appear to have problems if a sync is attempted
immediately after the device connects to the host computer. gnome-pilot
2.0.14 uses HAL to detect a palmos device, and so tends to attempt a
connection
It all sounds like a timing issue. There have been several reports of
regressions with minor udev updates, etc. It would be interesting if
someone was able to report back with their experience of disabling HAL
(see comment dated 2006-10-19 13:52:30 UTC) and/or libusb syncing.
It should be
It's somewhat unusual to see gnome-pilot failing when pilot-link is
reliable (especially in this way, which seems to be in the initial
handshake with the PDA).
Here are a few things to try:
1. Run pilot-xfer with a '-t 2' option. (This does the handshake in a way more
like gnome-pilot).
2.
[aside] not sure why launchpad is reporting upstream status as
'rejected'. It was accidentally marked 'invalid' by the upstream
reporter, but I reopened it today.
--
gpilotd locks up my Palm Z22
https://launchpad.net/bugs/66355
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
Jon,
your output suggests that you have '/dev/pilot' configured as your device name
in gnome-pilot, but that that device does not exist during the sync attempt.
Is this the device name you use with pilot-xfer? If not, configure gnome-pilot
using the configuration applet, and set the device
Okay, taking a closer look, those lines are just showing that there's a
gap between the usb device being detected and the creation of the
/dev/pilot symlink. At the end of the output we can see the 'poll',
which means we've found /dev/pilot and are trying to talk.
We've made some progress. The
Strange stuff. Looks like a timing issue.
I'd strongly recommend seeing if you can get libusb syncing to work.
What happened when you set the timeout to zero in gnome-pilot? Does it
just sit there forever trying to connect until you kill it? You didn't
send output for the gpilotd+timeout=0
Glad that the kernel update appears to solve this issue, and that
setting a non-zero timeout appears to solve the problem with the ttyUSB
devices hanging around after a sync completes. I'm pretty sure this
latter issue has been solved in gnome-pilot CVS, and the timeout=0 trick
is only required
I've just opened a bug at bugzilla.gnome.org, with a patch to fix this issue.
See:
http://bugzilla.gnome.org/show_bug.cgi?id=347905
--
Can't create folders in a mh mailbox
https://launchpad.net/bugs/50585
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
after reading Felix's bug, it's possible that my bug and patch is a
separate issue. I use a 'mh' backend, not 'maildir'. It seems likely
that our problems have a common cause, but I haven't tried verifying
with a maildir backend.
--
Can't create folders in a mh mailbox
see also #38574. It appears that the current 2.6.15 kernel is causing
the problems. There have been success stories after upgrading to
2.6.17.1, and one poster suggested a workaround is to start gpilotd a
second or two after initiating the sync. (open a terminal, do 'killall
gpilotd', start the
probably a duplicate of #38574.
--
unable to bind to pilot
https://launchpad.net/bugs/45986
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
fixed in gnome-pilot CVS.
--
applet isn't transparent in transparent panels
https://launchpad.net/bugs/45297
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
There's not much more to say on this one... it seems very likely that
the problem is with the ubuntu 2.6.15 kernel package and has been fixed
in more recent revisions. I'd advise building your own kernel, or
raising a bug against the kernel package.
--
Pb syncing treo 650 on dapper drake
What version is your kernel? Do: 'uname -r' in a terminal. The bug I
referred to above claims a problem with 2.6.15 was resolved with a pre-
release of the 2.6.17 kernel which has not been officially released yet.
I'm not saying the problem is resolved in up-to-date dapper. I believe
there may
Try Upgrading kernel... It seems there may well be some kernel/usbserial
bugs in the ubuntu 2.6.15 kernel that is screwing up ttyUSB connections.
See the following Ubuntu bug:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39518
--
Pb syncing treo 650 on dapper drake
see recent thread on gnome-pilot-list
This bug (and #45986, and maybe others?) appears to be caused by a kernel bug.
Matt Price reported a kernel oops, and it appears that unitialised memory has
been retruned by the ttyUSB device.
See:
Thanks, Franz.
The strace output is indeed helpful (although it is a bit frustrating that the
output doesn't appear to be complete - probably stderr hadn't finished
flushing before the process died).
It looks as though pilot-xfer dies in pilot-link's unixserial.c code, in the
function
s_open,
What version of pilot-link is shipping with Dapper?
For pilot-link 0.12, I have a couple more things to try out:
try using:
pilot-xfer -p usb: -l
(see thread here:
http://www.pilot-link.org/pipermail/pilot-link-general/2006-April/002721.html)
Also, for gnome-pilot, try setting the 'timeout' to
Hi, a couple of points from gnome-pilot.
The 'invalid free' bug has just been fixed in CVS. I don't know why it has
only recently shown up (it was reported on fedora) as the problem code was
rather old. Anyway, that's a straight bug.
Another problem has also been fixed, which may have caused
More info please!
Do you get any error message?
Try starting '/usr/libexec/gpilotd' from a terminal window (you might have to
kill any running gpilotd process first using 'killall gpilotd').
Cut and paste the gpilotd output after a crash.
--
Crashs when syncing with TE2
It looks like the evolution conduit is compiled for a more recent version of
pilot-link (0.12.0 pre-release) than gnome-pilot.
What version of pilot-link do you have installed?
If you start '/usr/libexec/gpilotd' by hand, it will display the version of
pilot-link it was compiled for.
do 'ldd
(sorry for misspelling your name, Franz...)
A couple more diagnostic tips:
have you tried the 'static device node' trick mentioned above? This basically
means doing something like:
# mknod /dev/pilot c 188 1
# chmod 0660 /dev/pilot
# chown :uucp /dev/pilot
to create a /dev/pilot device node
*** This bug is a duplicate of bug 33285 ***
This error may indicate that you haven't set a valid directory for backups, etc,
using the gnome-pilot applet. Try starting up gpilotd-control-applet,
'Add..'ing or
'Edit..'ing a Pilot entry, and setting a 'Local basedir' field.
A recent upstream
CVS version of gnome-pilot does use HAL.
I found, however, that the canned hal pda rules simply didn't work for me (fc5).
'lshal' showed the USB device, and the 'visor' enabled pseudo device, but
didn't report the pda capability, palmos identifier, ttyUSB port or anything.
The good news is that
IMO, no.
#25653 complained that gpilotd was looking for /proc/bus/usb/devices, and the
fix is to read /sys/bus/usb if it is available. This is now done (unless HAL
is being used...)
This bug, #30015, is complaining that gnome-pilot doesn't give the user any
guide to choosing the correct
55 matches
Mail list logo
