[Bug 653686] [NEW] Automatic non-login keyring unlock does not work
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 recording the password of the keyring to be unlocked. In Ubuntu 10.04 this worked correctly. In 10.10 RC, the option to automatically unlock a keyring is available but appears to do nothing. The selected keyring does not unlock automatically after logging out and back in. No entry is created in the login keychain with the relevant password. This behaviour can be reproduced in the Passwords and Encryption Keys manager. Create a new keyring and assign it a test password. Lock the keyring, then unlock again and select the automatic unlock option. Enter the test password and log out. On logging back in, the new keyring is not unlocked. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: gnome-keyring 2.92.92.is.2.31.91-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4 Uname: Linux 2.6.35-22-generic x86_64 NonfreeKernelModules: nvidia Architecture: amd64 Date: Sat Oct 2 18:12:37 2010 InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Release Candidate amd64 (20100928) ProcEnviron: LANG=en_GB.utf8 SHELL=/bin/bash SourcePackage: gnome-keyring ** Affects: gnome-keyring (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug maverick -- 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, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 653686] Re: Automatic non-login keyring unlock does not work
** 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, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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. It should be fixed there anyway (I had assumed a developer here would propagate this upstream to Debian) and if it is then it will probably be easier to get Ubuntu to adopt the patch. -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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%7Er1696.dfsg-9ubuntu1_amd64.deb -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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 bug report if you need a fix for it. This bug report is about the failure of mt-daapd to start without segfaulting in Jaunty. If you have no mt-daapd service at all then this report is relevant to you as well. To install the package with a fix for that, try this: sudo dpkg -i mt-daapd_0.9~r1696.dfsg-9ubuntu1_amd64.deb (I haven't come across that build-dep error before. Perhaps it needs an extra repository enabled in Synaptic? The binary package should work for you, anyhow.) -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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 Rhythmbox from a fresh boot. Relevant lines of the syslog look like this: May 16 16:13:59 ceres dhclient: Listening on LPF/wlan0/00:1c:bf:90:a4:c0 May 16 16:13:59 ceres dhclient: Sending on LPF/wlan0/00:1c:bf:90:a4:c0 May 16 16:13:59 ceres dhclient: Sending on Socket/fallback May 16 16:13:59 ceres dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 May 16 16:13:59 ceres kernel: [ 17.384085] wlan0: authenticate with AP 88007d0bfac0 May 16 16:13:59 ceres kernel: [ 17.385975] wlan0: authenticated May 16 16:13:59 ceres kernel: [ 17.385980] wlan0: associate with AP 88007d0bfac0 May 16 16:13:59 ceres kernel: [ 17.388574] wlan0: RX AssocResp from 88007d951026 (capab=0x411 status=0 aid=1) May 16 16:13:59 ceres kernel: [ 17.388580] wlan0: associated May 16 16:13:59 ceres kernel: [ 17.390822] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready May 16 16:13:59 ceres mt-daapd[2753]: Firefly Version svn-1696: Starting with debuglevel 2 May 16 16:13:59 ceres mt-daapd[2753]: Error loading plugin /usr/lib/mt-daapd/plugins/ssc-ffmpeg.so: /usr/lib/mt-daapd/plugins/ssc-ffmpeg.so: undefined symbol: avcodec_decode_audio May 16 16:13:59 ceres mt-daapd[2753]: Error loading plugin /usr/lib/mt-daapd/plugins/ssc-script.so: plugin declined to load May 16 16:13:59 ceres mt-daapd[2753]: Plugin loaded: daap/svn-1696 May 16 16:13:59 ceres mt-daapd[2753]: Plugin loaded: rsp/svn-1696 May 16 16:13:59 ceres mt-daapd[2753]: Starting signal handler May 16 16:13:59 ceres mt-daapd[2760]: Starting rendezvous daemon May 16 16:13:59 ceres mt-daapd[2760]: Client connecting May 16 16:14:00 ceres mt-daapd[2760]: Initializing database May 16 16:14:00 ceres mt-daapd[2760]: Full reload... May 16 16:14:00 ceres avahi-daemon[2813]: Found user 'avahi' (UID 110) and group 'avahi' (GID 119). May 16 16:14:00 ceres avahi-daemon[2813]: Successfully dropped root privileges. May 16 16:14:00 ceres avahi-daemon[2813]: avahi-daemon 0.6.23 starting up. May 16 16:14:00 ceres avahi-daemon[2813]: Successfully called chroot(). May 16 16:14:00 ceres avahi-daemon[2813]: Successfully dropped remaining capabilities. May 16 16:14:00 ceres acpid: client connected from 2785[0:0] May 16 16:14:01 ceres avahi-daemon[2813]: No service file found in /etc/avahi/services. May 16 16:14:01 ceres avahi-daemon[2813]: Network interface enumeration completed. May 16 16:14:01 ceres avahi-daemon[2813]: Registering new address record for fe80::21c:bfff:fe90:a4c0 on wlan0.*. May 16 16:14:01 ceres avahi-daemon[2813]: Server startup complete. Host name is ceres.local. Local service cookie is 2860126817. May 16 16:14:01 ceres avahi-daemon[2813]: Registering HINFO record with values 'X86_64'/'LINUX'. May 16 16:14:01 ceres mt-daapd[2760]: Client running May 16 16:14:01 ceres mt-daapd[2760]: Client registering May 16 16:14:03 ceres dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 May 16 16:14:03 ceres dhclient: DHCPOFFER of 192.168.1.21 from 82.70.152.20 May 16 16:14:03 ceres dhclient: DHCPREQUEST of 192.168.1.21 on wlan0 to 255.255.255.255 port 67 May 16 16:14:03 ceres dhclient: DHCPACK of 192.168.1.21 from 82.70.152.20 May 16 16:14:03 ceres avahi-daemon[2813]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.1.21. May 16 16:14:03 ceres avahi-daemon[2813]: New relevant interface wlan0.IPv4 for mDNS. May 16 16:14:03 ceres avahi-daemon[2813]: Registering new address record for 192.168.1.21 on wlan0.IPv4. May 16 16:14:04 ceres dhclient: bound to 192.168.1.21 -- renewal in 1591 seconds. May 16 16:14:04 ceres mt-daapd[2760]: Starting mp3 scan May 16 16:14:04 ceres mt-daapd[2760]: Starting playlist scan May 16 16:14:04 ceres mt-daapd[2760]: Updating playlists May 16 16:14:04 ceres mt-daapd[2760]: Error scanning MP3 files: No such file or directory May 16 16:14:04 ceres mt-daapd[2760]: Scanned 0 songs in 0 seconds May 16 16:14:04 ceres mt-daapd[2760]: Starting web server from /usr/share/mt-daapd/admin-root on port 3689 May 16 16:14:04 ceres mt-daapd[2760]: Registering rendezvous names May 16 16:14:04 ceres mt-daapd[2760]: Serving 0 songs. Startup complete in 0 seconds You can see mt-daapd and avahi-daemon starting concurrently before an IP has been associated with the wireless interface. As soon as it does, Avahi registers itself on the interface and the service appears on the network. It's possible that this load order doesn't reproduce the race you are experiencing or that the problem lies elsewhere. But that's where my assistance must stop, I'm afraid, since without a reproduction I would not be able to trace the problem. :( -- Applications can't connect to avahi-daemon
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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 on the Ethernet link.) 6) /etc/init.d/networking start I was then hoping that avahi-daemon would register the new interface but that the DAAP service would not be visible on the network. This wasn't the case, however, and mt-daapd appeared in a client machine's media player as soon as Avahi had done its thing. mt-daapd didn't need to disconnect or reregister. When I take my laptop home on Saturday I will try and reproduce this with a wireless connection. It's an Intel PRO/Wireless interface, so not a perfect match to your ath9k NIC, but it might exhibit similar problems. Without a reproduce this would be quite hard to fix, unfortunately. -- Applications can't connect to avahi-daemon until avahi is restarted once. https://bugs.launchpad.net/bugs/116984 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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 change. 5) [mt-daapd does not get readvertised on the right IP] It happens to work when you restart Avahi because: 1) mt-daapd disconnects from the stopped service. 2) Avahi starts up and registers on the available IPs. 3) mt-daapd connects and advertises its service. (The ordering of 2 and 3 is unsafe). Or when you restart mt-daapd because: 1) mt-daapd connects and advertises its service. The question of which daemon is at fault is not clear. I will take a closer look at the API tonight to determine which is the case, and plan an appropriate fix either way. -- Applications can't connect to avahi-daemon until avahi is restarted once. https://bugs.launchpad.net/bugs/116984 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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 ability to detect changes to the network configuration). That may or may not be the same problem you are experiencing. -- Applications can't connect to avahi-daemon until avahi is restarted once. https://bugs.launchpad.net/bugs/116984 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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? -- Applications can't connect to avahi-daemon until avahi is restarted once. https://bugs.launchpad.net/bugs/116984 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 116984] Re: Applications can't connect to avahi-daemon until avahi is restarted once.
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 entirely familiar with the protocol. Does restarting mt-daapd rather than Avahi fix the problem? -- Applications can't connect to avahi-daemon until avahi is restarted once. https://bugs.launchpad.net/bugs/116984 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 363768] Re: Jaunty - Rhythmbox doesn't show DAAP share
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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 /path/to/downloaded/13_avahi_fix_and_handle_restart.dpatch debian/patches dpkg-buildpackage -rfakeroot sudo dpkg -i ../*.deb After installing the new package you might find that 'apt-get upgrade' will want to reinstall the old version. You can either not install the new package and just copy the mt-daapd binary (bad but it'll work) or you can increment the package version number (bad because you might miss a real update). For the latter, do this before 'dpkg-buildpackage -rfakeroot': sudo apt-get install devscripts dch -i -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 331369] Re: regression vs. notification-daemon: positioning when multiple screens are available
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 occur if and only if there is no GNOME panel at the top of the screen. As you still have the top panel then you are experiencing a different bug arising from similar logic. I like your idea, Oli, although I am not sure if there is a reliable way to query the GNOME desktop to locate the notification area. The method for locating just the panel is rather cumbersome, albeit reasonably reliable; each window on the desktop is iterated in an attempt to match one with a specific class name. Perhaps the maintainers can think of a way? (There are additional structural problems in notify-osd which would need to be resolved to position the OSD at lower parts of the display. e.g. The height of the bubble is not currently known when the positioning logic is invoked, because it is not required when the bubble starts at the top and grows downwards.) -- regression vs. notification-daemon: positioning when multiple screens are available https://bugs.launchpad.net/bugs/331369 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 331369] Re: regression vs. notification-daemon: positioning when multiple screens are available
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 believe this design was intentional. The fallback path attempts to place the OSD at the top-right of the desktop area - which spans all monitors in a TwinView configuration and hence appears on the rightmost monitor. I am not sure what the correct solution is. I have made a private patch to fix this on my system but it is not suitable for wider release. -- regression vs. notification-daemon: positioning when multiple screens are available https://bugs.launchpad.net/bugs/331369 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 331369] Re: regression vs. notification-daemon: positioning when multiple screens are available
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 The full area is 3840x1200 and the OSD is placed just short of the far right on the second monitor. It does detect the right monitor at first; there seems to be some incorrect logic after that. -- regression vs. notification-daemon: positioning when multiple screens are available https://bugs.launchpad.net/bugs/331369 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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 gracefully. By reenabling this broken part of Firefly, a slew of race conditions between Firefly and Avahi, which were already present in the code, were exposed. The core of the problem is this: the avahi_simple_poll_* API makes it impossible to interact with from outside the event loop thread. This is by design and led to development of the thread-aware avahi_threaded_poll_* API. I have put together a preliminary patch to resolve this (attached). It passes Valgrind's Helgrind race condition checker in all live paths I have tested; previously, crash-causing races were detected in several places. It has one weakness: * _rend_avahi_lock/unlock are messily extended with a from_callback parameter. This was necessary because some locking code is shared by external threads and by the event thread (in callbacks) and Avahi provides no way to detect the thread context. Locking Avahi in the callback thread would otherwise lead to deadlock. This is a criticism of elegance and not functionality. I have tested the patch and am fairly happy with it. ** Attachment added: Fix thread-unsafe behaviour in upstream patch http://launchpadlibrarian.net/24479106/13_avahi_fix_and_handle_restart.dpatch -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 343069] Re: Avahi causing mt-daap to segfault
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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 188732] Re: Blinking cursor can not be deactivated anymore
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/gnome/gnome-terminal-2.22.1-reverseblink.patch For users wishing to restore blink functionality before the next milestone, apply like this: apt-get source gnome-terminal cd gnome-terminal-2.22.1 patch -p0 /path/to/gnome-terminal-2.22.1-reverseblink.patch dpkg-buildpackage -rfakeroot (from package dpkg-dev for this) sudo cp debian/tmp/usr/bin/* /usr/bin sudo cp debian/tmp/etc/gconf/schemas/* /etc/gconf/schemas sudo cp debian/tmp/usr/share/gnome-terminal/glade/* /usr/share/gnome-terminal/glade (You will need to use another terminal, like xterm, to overwrite the gnome-terminal binary. I'd advise against installing the whole built .dpkg file as it will conflict with the apt repository.) -- Blinking cursor can not be deactivated anymore https://bugs.launchpad.net/bugs/188732 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 188732] Re: Blinking cursor can not be deactivated anymore
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. -- Blinking cursor can not be deactivated anymore https://bugs.launchpad.net/bugs/188732 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
