** Attachment added: "Dependencies.txt"
https://bugs.launchpad.net/bugs/653686/+attachment/1666995/+files/Dependencies.txt
--
Automatic non-login keyring unlock does not work
https://bugs.launchpad.net/bugs/653686
You received this bug notification because you are a member of Ubuntu
Bugs, wh
Public bug reported:
Binary package hint: gnome-keyring
The GNOME Keyring has a facility to automatically unlock keyrings, other
than the login keyring, when the user logs in. This option can be
selected whenever the keyring is unlocked by hand, resulting in a new
entry in the login keyring recor
I am not sure how the process works either.
One thing you could do is chase this upstream to the Debian maintainer
who added the broken patch, which Ubuntu then inherited. If you look at
my patch it is actually patching *another* patch which was added and
maintained by Debian to fix a few problems
Hi Dave,
Sorry, perhaps I was unclear about those warnings. They indicate a
genuine bug in the mt-daapd package which has been around for quite a
while in Ubuntu's package, from what I recall. It could indeed cause
failures in transcoding if you rely on that feature and you should make
a separate
Those messages aren't a problem. (Well, they are, but they're unrelated
to this bug!)
For completeness I've attached a patched AMD64 package. That should fix
your problem.
** Attachment added: "mt-daapd binary package with proposed patch"
http://launchpadlibrarian.net/26923010/mt-daapd_0.9%7E
Right, I've tried to reproduce this with the help of my laptop. After
configuring it to make a wireless connection (with the iwl3945 Intel
PRO/Wireless driver) on boot, outside of NetworkManager, and installing
patched mt-daapd it successfully appears on a wired client's shared
library list in Rhyt
The bad news is I wasn't able to reproduce this last night.
To simulate the problem, I did:
1) /etc/init.d/mt-daapd stop
2) /etc/init.d/avahi-daemon stop
3) /etc/init.d/networking stop
4) /etc/init.d/avahi-daemon start
5) /etc/init.d/mt-daapd start
(At this point, mt-daapd is registered but not
Thanks for testing that.
This means it is likely that the problem lies with Avahi or in
miscommunication between mt-daapd and Avahi. The problem seems to be
this:
1) Avahi starts up.
2) mt-daapd connects and advertises its service.
3) DHCP assigns an IP to the system.
4) Avahi acknowledges the IP
Hmm, that looks OK.
All I can think of is that mt-daapd registers with Avahi after it starts
but before it has registed an address record (due to the late DHCP). On
my system mt-daapd registers after Avahi has registered addesses.
One would expect Avahi to handle this gracefully but I am not enti
Regarding my above comment, I think I read that log a little too
quickly. avahi-autoipd is detecting a Zeroconf address but this is after
registering the correct IP on eth0, so this should work fine.
In addition to the relevant entries from your syslog, could you also say
which NIC you're using?
Can you paste your syslog entries for Avahi following a bad startup and
successful daemon restart?
>From davebv's syslog, it appears that avahi-daemon is being started
before an IP address has been assigned to the machine. That's a startup
ordering issue (and secondarily a weakness in Avahi's abil
I've seen this problem periodically with some NICs.
Switch to an Intel NIC made it go away, so I suspected a broken
multicast implementation in the driver.
--
Jaunty - Rhythmbox doesn't show DAAP share
https://bugs.launchpad.net/bugs/363768
You received this bug notification because you are a me
Ah, sorry. I dropped that patch in for the maintainer and omitted an
explanation of how to apply it for users to experiment with.
You need to do this:
sudo apt-get install dpkg-dev fakeroot
sudo apt-get build-dep mt-daapd
apt-get source mt-daapd [no sudo on this one]
cd mt-daapd-0.9~r1696.dfsg
cp
Ryan, my analysis is not incompatible with your problem.
The positioning logic in notify-osd is not very sophisticated and
TwinView, which the developers may not have been able to perform
substantial testing under, introduces additional complications. One
problem, which I described above, will occ
I've taken some time to investigate this properly.
This problem will arise on an NVIDIA TwinView configuration when there
is no GNOME panel at the top of the screen; either through being removed
or moved elsewhere. notify-osd is programmed to follow the top panel
only, quite explicitly and I belie
I still have this problem with 0.9.11-0ubuntu3 on a TwinView setup.
Here's the output of notify-osd:
** (notify-osd:6226): DEBUG: selecting monitor 0 at (0,0) - 1920x1200
** (notify-osd:6226): DEBUG: no panel detetected; using workarea fallback
** (notify-osd:6226): DEBUG: top corner at: 3550, -2
OK, I had some time to debug this.
The problem is caused by a thread-unsafe patch introduced by the
upstream maintainer (in
debian/patches/13_avahi_fix_and_handle_restart.dpatch). This patch was
intended to restore Firefly's broken Avahi handler so that daemon
reconnections could be handled gracef
Confirming this problem.
A standalone build of SVN 1737 (with HAVE_VA_COPY fix) works fine with
Avahi.
--
Avahi causing mt-daap to segfault
https://bugs.launchpad.net/bugs/343069
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
It is unfortunate that the upstream developers chose to deal with this
matter in the manner in which they have done.
I will assume by Pedro's comment that all is now in hand, but in case it helps
here is a reversal of the offending patch against 8.04's sources:
http://www.jcornwall.me.uk/patches/
I installed Hardy RC1 today and this feature revocation really annoyed
me.
Until a proper patch is in the works, I threw together this to force blinking
off in the terminal:
http://www.jcornwall.me.uk/2008/04/hardy-heron-and-the-blinkin-terminal/
Source patch and optional binaries for the lazy.
20 matches
Mail list logo
