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 message
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 EDS_CHECK_V
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 disks
** 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.
--
desk
** 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.
--
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 cra
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.
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
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 ev
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
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
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
port.
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
https://l
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
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 not
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
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
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 bac
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
you want to use the applet, you'll 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 Dav
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 ref
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
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. c
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 ver
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 'u
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,
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 whethe
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
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 co
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 poss
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 case
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
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 nam
[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
https:/
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. Ru
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 fo
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
https://lists.ubuntu.com/mailman
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
https://launchpad.net/bug
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
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
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
https:
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
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:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39518
In which a user fi
Do you have usbfs mounted? Is this a duplicate of:
http://bugzilla.gnome.org/show_bug.cgi?id=336473
(and other ubuntu bugs)
Try 'mount -t usbfs /proc/bus/usb'.
--
syncing with Tungsten E2 does not work
https://launchpad.net/bugs/46252
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.
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
http
This may well be related to:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/39518
i.e. a kernel bug that affects ttyUSB devices. Try upgrading your
kernel and see if the problem resolves itself.
--
Crashs when syncing with TE2
https://launchpad.net/bugs/43767
--
desktop-
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, bet
I don't think I can help much more at this point as I'm not a Ubuntu
user.
It sounds like it might be a kernel problem. What I'd suggest is
turning on debugging information in pilot-xfer, and running a system-
call level trace:
You can get more information from pilot-xfer by
setting the environm
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
(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 tha
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 /us
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
https://launchpad.net/bug
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
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 ttyUS
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 th
*** 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 bu
58 matches
Mail list logo
